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CHAPTER  1 


INTRODUCTION 


The  Ada  implementation  described  above  was  tested  according  to  the 
Ada  Validation  Procedures  [Pro90]  against  the  Ada  Standard  [Ada83] 
using  the  current  Ada  Compiler  Validation  Capability  (ACVC) .  This 
Validation  Sixmmary  Report  (VSR)  gives  an  account  of  the  testing  of 
this  Ada  implementation.  For  any  technical  terms  used  in  this 
report,  the  reader  is  referred  to  [Pro90].  A  detailed  description 
of  the  ACVC  may  be  found  in  the  current  ACVC  User's  Guide  [UG89]. 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the 
Ada  Certification  Body  may  make  full  and  free  public  disclosure  of 
this  report.  In  the  United  States,  this  is  provided  in  accordance 
with  the  "Freedom  of  Information  Act"  (5  U.S.C.  #552)  .  The  results 
of  this  validation  apply  only  to  the  computers,  operating  systems, 
and  compiler  versions  identified  in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report 
do  not  represent  or  warrant  that  all  statements  set  forth  in  this 
report  are  accurate  and  complete,  or  that  the  subject 
implementation  has  no  nonconformities  to  the  Ada  Standard  other 
than  those  presented.  Copies  of  this  report  are  available  to  the 
public  from  the  AVF  which  performed  this  validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 

Questions  regarding  this  report  or  the  validation  test  results 
should  be  directed  to  the  AVF  which  performed  this  validation  or 
to: 


Ada  Validation  Organization 

Computer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria  VA  22311-1772 


1.2  REFERENCES 

[Ada83]  Reference  Manual  for  the  Ada  Programming  Language. 

ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987. 
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[Pro90]  Ada  Compiler  Validation  Procedures.  Version  2.1,  Ada  Joint 
Program  Office,  August  1990. 


[UG89]  Ada  Compiler  Validation  Capability  User's  Guide.  21  June 
1989. 


1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC. 
The  ACVC  contains  a  collection  of  test  programs  structured  into  six 
test  classes:  A,  B,  C,  D,  E,  and  L.  The  first  letter  of  a  test 
name  identifies  the  class  to  which  it  belongs.  Class  A,  C,  D,  and 
E  tests  are  executable.  Class  B  and  class  L  tests  are  expected  to 
produce  errors  at  compile  time  and  link  time,  respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and 
produce  a  PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the 
result  when  they  are  executed.  Three  Ada  library  units,  the 
packages  REPORT  and  SPPRT13,  and  the  procedure  CHECK_FILE  are  used 
for  this  purpose.  The  package  REPORT  also  provides  a  set  of 
identity  functions  used  to  defeat  some  compiler  optimizations 
allowed  by  the  Ada  Standard  that  would  circumvent  a  test  objective. 
The  package  SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the  Ada 
Standard.  The  procedure  CHECK_FILE  is  used  to  check  the  contents 
of  text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14 
of  the  Ada  Standard.  The  operation  of  REPORT  and  CHECK_FILE  is 
checked  by  a  set  of  executable  tests.  If  these  units  are  not 
operating  correctly,  validation  testing  is  discontinued. 

Class  B  tests  check  that  a  compiler  detects  illegal  language  usage. 
Class  B  tests  are  not  executable.  Each  test  in  this  class  is 
compiled  and  the  resulting  compilation  listing  is  examined  to 
verify  that  all  violations  of  the  Ada  Standard  are  detected.  Some 
of  the  class  B  tests  contain  legal  Ada  code  which  must  not  be 
flagged  illegal  by  the  compiler.  This  behavior  is  also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects 
violation  of  the  Ada  Standard  involving  multiple,  separately 
compiled  units.  Errors  are  expected  at  link  time,  and  execution  is 
attempted . 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be 
replaced  by  implementation-specific  values  —  for  example,  the 
largest  integer.  A  list  of  the  values  used  for  this  implementation 
is  provided  in  Appendix  A.  In  addition  to  these  anticipated  test 
modifications,  additional  changes  may  be  required  to  remove 
unforeseen  conflicts  between  the  tests  and  implementation-dependent 
characteristics.  The  modifications  required  for  this 
implementation  are  described  in  section  2.3. 
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For  each  Ada  implementation,  a  customized  test  suite  is  produced  by 
the  AVF.  This  customization  consists  of  making  the  modifications 
described  in  the  preceding  paragraph,  removing  withdrawn  tests  (see 
section  2.1)  and,  possibly  some  inapplicable  tests  (see  Section  3.2 
and  [UG89]) . 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each 
test  of  the  customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 


Ada  Compiler  The  software  and  any  needed  hardware  that  have  to 
be  added  to  a  given  host  and  target  computer 
system  to  allow  transformation  of  Ada  programs 
into  executable  form  and  execution  thereof. 


Ada  Compiler 
Validation 
Capability 
(ACVC) 


The  means  for  testing  compliance  of  Ada 
implementations.  Validation  consisting  of  the 
test  suite,  the  support  programs,  the  ACVC 
Capability  user's  guide  and  the  template  for 
the  validation  summary  (ACVC)  report. 


Ada  An  Ada  compiler  with  its  host  computer  system  and 

Implementation  its  target  computer  system. 


Ada  Joint  The  part  of  the  certification  body  which  provides 

Program  policy  and  guidance  for  the  Ada  certification  Office 

(AJPO)  system. 

Ada  The  part  of  the  certification  body  which  carries 

Validation  out  the  procedures  required  to  establish  the 
Facility  (AVF)  compliance  of  an  Ada  implementation. 

Ada  The  part  of  the  certification  body  that  provides 

Validation  technical  guidance  for  operations  of  the  Ada 
Organization  certification  system. 

(AVO) 

Compliance  of  The  ability  of  the  implementation  to  pass  an  ACVC 
an  Ada  version. 

Implementation 

Computer  A  functional  unit,  consisting  of  one  or  more 

System  computers  and  associated  software,  that  uses 

common  storage  for  all  or  part  of  a  program  and 
also  for  all  or  part  of  the  data  necessary  for 
the  execution  of  the  program;  executes 
user-written  or  user-designated  programs;  performs 
user-designated  data  manipulation,  including 
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Conformity 


Customer 


Declaration  of 
Conformance 


Host  Computer 
System 

Inapplicable 

test 


ISO 

LRM 


Operating 

System 


Target 

Computer 

System 

Validated  Ada 
Compiler 

Validated  Ada 
Implementation 


arithmetic  operations  and  logic  operations;  and 
that  can  execute  programs  that  modify  themselves 
during  execution.  A  computer  system  may  be  a 
stand-alone  unit  or  may  consist  of  several 
inter-connected  units. 

Fulfillment  by  a  product,  process  or  service  of 
all  requirements  specified. 

An  individual  or  corporate  entity  who  enters  into 
an  agreement  with  an  AVF  which  specifies  the  terms 
and  conditions  for  AVF  services  (of  any  kind)  to 
be  performed. 

A  formal  statement  from  a  customer  assuring  that 
conformity  is  realized  or  attainable  on  the  Ada 
implementation  for  which  validation  status  is 
realized. 

A  computer  system  where  Ada  source  programs  are 
transformed  into  executable  form. 

A  test  that  contains  one  or  more  test  objectives 
found  to  be  irrelevant  for  the  given  Ada 
implementation . 

International  Organization  for  Standardization. 

The  Ada  standard,  or  Language  Reference  Manual, 
published  as  ^SI/MIL-STD-1815A-1983  and  ISO 
8652-1987.  Citations  from  the  LRM  take  the  form 
"<section> . <subsection> : <paragraph> . ” 

Software  that  controls  the  execution  of  programs 
and  that  provides  services  such  as  resource 
allocation,  scheduling,  input/ output  control, 
and  data  management.  Usually,  operating  systems 
are  predominantly  software,  but  partial  or 
complete  hardware  implementations  are  possible. 

A  computer  system  where  the  executable  form  of  Ada 
programs  are  executed. 


The  compiler  of  a  validated  Ada  implementation. 


An  Ada  implementation  that  has  been  validated 
successfully  either  by  AVF  testing  or  by 
registration  [Pro903. 


1-4 


Validation 


Withdrawn 

test 


The  process  of  checking  the  conformity  of  an  Ada 
compiler  to  the  Ada  programming  language  and  of 
issuing  a  certificate  for  this  implementation. 

A  test  found  to  be  incorrect  and  not  used  in 
conformity  testing.  A  test  may  be  incorrect 
because  it  has  an  invalid  test  objective,  fails 
to  meet  its  test  objective,  or  contains  erroneous 
or  illegal  use  of  the  Ada  programming  language. 
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CHAPTER  2 


IMPLEMENTATION  DEPEN'DENCIES 


2.1  WITHDRAWN  TESTS 

Some  tests  are  withdravm  by  the  AVO  from  the  ACVC  because  they  do 
not  conform  to  the  Ada  Standard.  The  following  95  tests  had  been 
withdrawn  by  the  Ada  Validation  Organization  (AVO)  at  the  time  of 
validation  testing.  The  rationale  for  withdrawing  each  test  is 
available  from  either  the  AVO  or  the  AVF.  The  publication  date  for 
this  list  of  withdrawn  tests  is  91-08-02. 


E28005C 

B28006C 

C32203A 

C34006D 

C35508I 

C35508J 

C35508M 

C35508N 

C35702A 

C35702B 

B41308B 

C43004A 

C45114A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A 

C46022A 

B49008A 

B49008B 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

B83026B 

C83026A 

C83041A 

B85001L 

C86001F 

C94021A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

A01B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

B03006A 

B04008A 

CD4022A 

C04022D 

CD4024B 

CD4024C 

CD40240 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

B08004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2 . 2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  which  are 
irrelevant  for  a  given  Ada  implementation.  The  inapplicability 
criteria  for  some  tests  are  explained  in  documents  issued  by  ISO 
and  the  AJPO  known  as  Ada  Commentaries  and  commonly  referenced  in 
the  format  Al-ddddd.  For  this  implementation,  the  following  tests 
were  determined  to  be  inapplicable  for  the  reasons  indicated; 
references  to  Ada  Commentaries  are  included  as  appropriate. 

The  following  198  tests  have  floating-point  type  declarations 
requiring  more  digits  than  SYSTEM. MAX_DIGITS; 


C24113L..V  (11  tests) 
C35706L. .Y  (14  tests) 
C35708L..Y  (14  tests) 
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C35705L. .Y  (14  tests) 
C35707L. .Y  (14  tests) 
C35802L. .Z  (15  tests) 


C45241L. .Y  (14  tests) 
C45421L. .Y  (14  tests) 
C45524L. .Z  (15  tests) 
C45641L. .Y  (14  tests) 

C24113W.  .Y  (3  tests)  use  a  line 
exceeds  255  characters. 


C45321L. .Y  (14  tests) 

C45521L. .Z  (15  tests) 

C45621L. .Z  (15  tests) 

C46012L. .Z  (15  tests) 

length  in  the  input  file  which 


The  following  20  tests  check  for  the  predefined  type  IiONG_INTEGER; 
for  this  implementation,  there  is  no  such  type: 


C35404C 

C45231C 

C45304C 

C45411C 

C45412C 

C45502C 

C45503C 

C45504C 

C45504F 

C45611C 

C45613C 

C45614C 

C45631C 

C45632C 

B52004D 

C55B07A 

B55B09C 

B86001W 

C86006C 

CD7101F 

C35713B,  C45423B,  B86001T,  and  C86006H  check  for  the  predefined 
type  SHORT_FLOAT;  for  this  implementation,  there  is  no  such  type. 

C35713D  and  B86001Z  check  for  a  predefined  floating-point  type  with 
a  name  other  than  FLOAT,  LONG_FLOAT,  or  SHORT_FLOAT ;  for  this 
implementation,  there  is  no  such  type. 

C45531M..P  and  C45532M..P  (8  tests)  check  fixed-point  operations 
for  types  that  require  a  SYSTEM. MAX_MANTISSA  of  47  or  greater;  for 
this  implementation,  MAX__MANTISSA  is  less  than  47. 

C45624A..B  (2  tests)  check  that  the  proper  exception  is  raised  if 
MACHINE_OVERFLOWS  is  FALSE  for  floating  point  types  and  the  results 
of  various  floating-point  operations  lie  outside  the  range  of  the 
base  type;  for  this  implementation,  MACHINE_OVERFLOWS  is  TRUE. 

B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than 
type  DURATION;  for  this  implementation,  there  is  no  such  type. 

B91001H  checks  that  an  address  clause  may  not  precede  an  entry 
declaration;  this  implementation  does  not  support  address  clauses 
for  entries.  (See  section  2.3.) 

C96005B  uses  values  of  type  DURATION'S  base  type  that  are  outside 
the  range  of  type  DURATION;  for  this  implementation,  the  ranges  are 
the  same. 

CD1009C  checks  whether  a  length  clause  can  specify  a  non-default 
size  for  a  floating-point  type;  this  implementation  does  not 
support  such  sizes. 

CD2A84A,  CD2A84E,  CD2A84I..J  (2  tests),  and  CD2A840  use  length 
clauses  to  specify  non-default  sizes  for  access  types;  this 
implementation  does  not  support  such  sizes. 
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CD2B15B  checks  that  STORAGE  ERROR  is  raised  when  the  storage  size 
specified  for  a  collection  Ts  too  small  to  hold  a  single  value  of 
the  designated  type;  this  implementation  allocates  more  space  than 
was  specified  by  the  length  clause,  as  allowed  by  AI-00558. 

BD8001A,  BD8003A,  BD8004A. .B  (2  tests),  and  AD8011A  use  machine 
code  insertions;  this  implementation  provides  no  package 
MACHINE_CODE. 

The  18  tests  listed  in  the  following  table  check  that  USE_ERROR  is 
raised  if  the  given  file  operations  are  not  supported  for  the  given 
combination  of  mode  and  access  method;  this  implementation  supports 
these  operations. 


Test 

File  Operation  Mode 

File  Access  Method 

CE2102E 

CREATE 

OUT  FILE 

SEQUENTIAL  10 

CE2102F 

CREATE 

INOUT  FILE 

DIRECT  10 

CE2102J 

CREATE 

OUT  FILE 

DIRECT  10 

CE2102N 

OPEN 

IN  FILE 

SEQUENTIAL  10 

CE21020 

RESET 

IN  FILE 

SEQUENTIAL  10 

CE2102P 

OPEN 

OUT  FILE 

SEQUENTIAL  10 

CE2102Q 

RESET 

OUT  FILE 

SEQUENTIAL  10 

CE2102R 

OPEN 

INOUT  FILE 

DIRECT  10 

CE2102S 

RESET 

INOUT  FILE 

DIRECT  10 

CE2102T 

OPEN 

IN  FILE 

DIRECT  10 

CE2102U 

RESET 

IN  FILE 

DIRECT  10 

CE2102V 

OPEN 

OUT  FILE 

DIRECT  10 

CE2102W 

RESET 

OUT  FILE 

DIRECT  10 

CE3102F 

RESET 

Any  Mode 

TEXT  10 

CE3102G 

DELETE 

TEXT  10 

CE3102I 

CREATE 

OUT  FILE 

TEXT  10 

CE3102J 

OPEN 

IN  FILE 

TEXT  10 

CE3102K 

OPEN 

OUT  FILE 

TEXT_IO 

The  tests  listed 

in  the  following  table 

check  the  given  file 

operations  for  the 

given  combination  of  mode  and  access  method; 

this  implementation  does  not 

support  these  ( 

operations . 

Test 

File  Operation  Mode 

File  Access  Method 

CE2105A 

CREATE 

IN  FILE 

SEQUENTIAL  10 

CE2105B 

CREATE 

IN  FILE 

DIRECT  10 

CE3109A 

CREATE 

IN  FILE 

TEXT  10 

CE2107C..D  (2  tests),  CE2107H 

,  and  CE2107L  apply  function  NAME  to 

temporary  sequential ,  direct 

,  and  text  files  in  an  attempt  to 

associate  multiple 

internal 

files  with  the  same  external  file; 

USE_ERROR  is  raised  because  temporary  files 

have  no  name. 
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CE2108B,  CE2108D«  and  CE3112B  use  the  names  of  temporary 
sequential,  direct,  and  text  files  that  were  created  in  other  tests 
in  order  to  check  t^at  the  temporary  files  are  not  accessible  after 
the  completion  of  those  tests;  for  this  implementation,  temporary 
files  have  no  name. 

CE2203A  checks  that  WRITE  raises  US£_ERROR  if  the  capacity  of  an 
external  sequential  file  is  exceeded;  this  implementation  cannot 
restrict  file  capacity. 

CE2401H,  EE24010,  and  EE2401G  use  instantiations  of  DIR£CT_IO  with 
unconstrained  array  and  record  types;  this  implementation  raises 
USE_ERROR  on  the  attempt  to  create  a  file  of  such  types. 

CE2403A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  an 
external  direct  file  is  exceeded;  this  implementation  cannot 
restrict  file  capacity. 

CE3304A  checks  that  SET_LINE_LENGTH  and  SET_PAGE_LENGTH  raise 
USE_ERROR  if  they  specify  an  inappropriate  value'  ‘for  the  external 
file;  there  are  no  inappropriate  values  for  this  implementation. 

CE3413B  checks  that  PAGE  raises  LAYOUT_ERROR  when  the  value  of  the 
page  number  exceeds  COUNT 'LAST;  for  this  implementation,  the  value 
of  COUNT 'LAST  is  greater  than  150000,  making  the  checking  of  this 
objective  impractical. 


2 . 3  TEST  MODIFICATIONS 

MODIFICATIONS  (SEE  SECTION  1.3)  WERE  REQUIRED  FOR  20  TESTS. 

The  19  tests  listed  below  were  graded  passed  by  Processing 
Modification  as  directed  by  the  AVO.  These  tests  make  various 
checks  that  CONSTRAINT_ERROR  is  raised  for  certain  operations  when 
the  resultant  values  lie  outside  of  the  range  of  the  siibtype. 
However,  in  many  of  the  particular  checks  that  these  tests  make, 
the  exception-raising  operation  may  be  avoided  as  per  LRM  11.6(7} 
by  optimization  that  removes  the  operation  if  its  only  possible 
effect  is  to  raise  an  exception  (e.g.,  an  assignment  to  a  variable 
that  is  not  later  referenced) .  In  the  list  below,  beside  the  name 
of  each  affected  test  is  given  the  line  number  of  either  the  check 
that  is  skipped,  or  the  call  to  FAILED  that  is  made — numbers  will 
be  within  brackets  in  the  latter  case.  These  tests  were  processed 
both  with  and  without  optimization:  the  tests  reported  a  passed 
result  without  optimization;  with  optimization,  the  checks 
indicated  below  were  skipped  and  REPORT . FAILED  was  called  (in  the 
case  of  C38202A,  execution  is  suspended  as  one  task  waits  for  a 
call  that  is  avoided) . 
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Check  [Failed]  Line  # 


Optimization : 

Elimination  of  assignment  statements 

C36204A 

113  &  118 

C36305A 

53  &  48 

C38202A 

35  (task  DRIVER  hangs) 

C45614A 

47  &  59 

C94001E  &  C94001F  36 

CC3305A 

37 

CC3305B. .D 

33 

Optimization : 

Elimination  of  pareuneter  assignments 

C64103A 

51,  91,  &  119 

C64103B 

90  &  99 

C64104A 

90,  103,  114,  126,  142,  158,  &  174 

C64104N 

[62] 

CE3704C 

109 

CE3804F 

114 

CE3804P 

113 

Optimization: 

Dead-store  elimination 

CB4006A 

[41  &  60] 

(line  29  initialization  is  eliminated) 

Optimization: 

Elimination  of  generic  actual  parameter 
evaluation. 

CC3125C 

51,  64,  100,  &  113 

B91001H  was  graded  inapplicable  by  Evaluation  Modification  as 
directed  by  the  AVO.  This  test  expects  an  error  to  be  cited  for  an 
entry  declaration  that  follows  an  address  clause  for  a  preceding 
entry;  but  this  implementation  does  not  support  address  clauses  for 
entries  (rather,  it  provides  a  package  that  allows  a  task  to  wait 
for  the  delivery  of  one  or  more  signals) ,  and  so  rejects  the 
address  clause. 
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CHAPTER  3 


PROCESSING  INFORMATION 


3 . 1  TESTING  ENVIRONMENT 

The  Ada  implementation  tested  in  this  validation  effort  is 
described  adequately  by  the  information  given  in  the  initial  pages 
of  this  report. 

For  technical  and  sales  information  about  this  Ada  implementation, 
contact : 


Attn :  Pat  Bernard 
Ada  Product  Manager 
Digital  Equipment  Corporation 
110  Spit  Brook  Road  (ZK02-1/M11) 
Nashua,  NH  03062 
(603)  881-0247 


Testing  of  this  Ada  implementation  was  conducted  at  the  customer's 
site  by  a  validation  team  from  the  AVF. 

3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes 
each  test  of  the  customized  test  suite  in  accordance  with  the  Ada 
Prograinming  Language  Standard,  whether  the  test  is  applicable  or 
inapplicable;  otherwise,  the  Ada  Implementation  fails  the  ACVC 
[Pro90] . 

For  all  processed  tests  (inapplicable  and  applicable) ,  a  result  was 
obtained  that  conforms  to  the  Ada  Programming  Language  Standard. 

The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various 
categories.  All  tests  were  processed,  except  those  that  were 
withdrawn  because  of  test  errors  (item  b;  see  section  2.1),  those 
that  require  a  floating-point  precision  that  exceeds  the 
implementation's  maximum  precision  (item  e;  see  section  2.2),  and 
those  that  depend  on  the  support  of  a  file  system  —  if  none  is 
supported  (item  d)  .  All  tests  passed,  except  those  that  are  listed 
in  sections  2.1  and  2.2  (counted  in  items  b  and  f,  below). 

a)  Total  Number  of  Applicable  Tests  3788 

b)  Total  Number  of  Withdrawn  Tests  95 

c)  Processed  Inapplicable  Tests  287 
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0 


d)  Non-Processed  I/O  Tests 

e)  Non-Processed  Floating-Point 

Precision  Tests  0 

f)  Total  Number  of  Inapplicable  Tests  287  (c+d+e) 

g)  Total  Number  of  Tests  for  ACVC  l.ll  4170  (a+b+f) 


3 . 3  TEST  EXECUTION 

A  magnetic  tape  containing  the  customized  test  suite  (see  section 
1.3)  was  taken  on-site  by  the  validation  team  for  processing.  The 
contents  of  the  magnetic  tape  were  loaded  directly  onto  the  host 
computer . 

After  the  test  files  were  loaded  onto  the  host  computer,  the  full 
set  of  tests  was  processed  by  the  Ada  implementation. 

The  tests  were  compiled,  linked,  and  executed  on  the  host/target 
computer  system. 

Testing  was  performed  using  command  scripts  provided  by  the 
customer  and  reviewed  by  the  validation  team.  See  Appendix  B  for 
a  complete  listing  of  the  processing  options  for  this 
implementation.  It  also  indicates  the  default  options.  The 
options  invoked  explicitly  for  validation  testing  during  this  test 
were : 

The  default  compiler  options  were  used  except  as  follows: 

The  source  listing  option  (-V)  was  specified  to  obtain  source 
listings  for  some  tests  and  a  high  error  limit  (-e99999)  was 
also  specified.  (By  default  a  compilation  is  aborted  once  30 
errors  have  been  reported.) 


Test  output,  compiler  and  linker  listings,  and  job  logs  were 
captured  on  magnetic  tape  and  archived  at  the  AVF.  The  listings 
examined  on-site  by  the  validation  team  were  also  archived. 
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APPENDIX  A 


MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing 
the  ACVC.  The  meaning  and  purpose  of  these  parameters  are 
explained  in  [UG89].  The  parameter  values  are  presented  in  two 
tables.  The  first  table  lists  the  values  that  are  defined  in  terms 
of  the  maximum  input-line  length,  which  is  the  value  for 
$MAX_IN_IjEN — also  listed  here.  These  values  are  expressed  here  as 
Ada  string  aggregates,  where  "V"  represents  the  maximum  input-line 
length. 

Macro  Parameter  Macro  Value 


$MAX_IN_LEN  255  —  Value  of  V 

$BIG_ID1  (1..V-1  =>  'A',  V  =>  '1') 

$BIG_ID2  (1..V-1  =>  'A',  V  =>  '2') 

$BIG_ID3  (1..V/2  =>  ‘A’)  &  ’3’  &  (1..V-1-V/2  =>  'A') 

$BIG_ID4  (1..V/2  =>  'A')  &  *4'  &  (1..V-1-V/2  =>  'A') 

$BIG_INT_LIT  (1..V-3  =>  ’O')  &  ''298'' 

$BIG_REAL_LIT  (1..V-5  =>  ' 0 ' )  &  "690 . 0" 

$BIG_STRING1  ""  &  (1..V/2  =>  'A')  &  "" 

$BIG_STRING2  ""  &  {1..V-1-V/2  =>  'A')  &  '1'  &  "" 

$BLANKS  (1..V-20  =>  '  ' ) 

$MAX_LEN_INT_BASED_LITERAL 

"2;"  &  (1..V-5  =>  '0')  &  "11;" 

$MAX_LEN_REAL_BASED_LITERAL 

"16;"  &  (1..V-7  =>  '0')  &  "F.E;" 

$MAX_STRING_LITERAL  ""  &  (1..V-2  =>  'A')  &  "" 
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The  following  table  contains  the  values  for  the  remaining 
macro  parameters. 

Macro  Parameter  Macro  Value 


$ACC_SIZE 

$ALIGNMENT 

$COUNT_LAST 

$  DEFAULT_MEM_S I Z  E 

$DEFAULT_STOR_UNIT 

$DEFAULT_SYS_NAME 

$DELTA_DOC 

$ENTRY_ADDRESS 

$ENTRY_ADDRES  S 1 

$ENTRY_ADDRESS2 

$FIELD_LAST 

$FILE_TERMINATOR 

$FIXED_NAME 

$FLOAT_NAME 

$FORM_STRING 

$F0RM_STRING2 

$GREATER_THAN_DURATION 

$GREATER_THAN_DURATION_BASE 


32 
4 

2_147_483_647 
2**31-1 
8 

RISC_ULTRIX 
2.0**(-31) 

FCNDECL. ENTRY_ADDRESS 
FCNDECL . ENTRY_ADDRESS 1 
FCNDECL. ENTRY_ADDRESS2 
2_147_483_647 

I  • 

NO_SUCH_FIXED_TYPE 
NO_SUCH_TYPE 

nn 

'•CANNOT_RESTRICT_FILE_CAPACITY'' 
75_000.0 
LAST  131  073.0 


$GREATER  THAN  FLOAT  BASE  LAST  1.80141E+38 


$GREATER_THAN_FLOAT_S AFE_LARGE  1. 7014117 E+ 38 


$GREATER  THAN  SHORT  FLOAT  SAFE  LARGE  1.0E308 


$HIGH  PRIORITY 


15 
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$ILLEGAL_EXTERNAL_FILE_NAME1  BAD/ CHAR*  § . - ! 
$ILLEGAL_EXTERNAL_FILE_NAME2  x"&  ( 1 .  .  256=> ' c ' )  &''y 
$INAPPROPRIATE_LINE_LENGTH  -1 

$INAPPROPRIATE_PAGE_LENGTH  -1 

$ INCLUDE  PRAGMAl 


$ INCLUDE_PRAGMA2 
$INTEGER_FIRST 
$INTEGER_LAST 
$ INTEGER_LAST_PLUS_1 
$ INTERF ACE_LANGUAGE 
$LESS  THAN  DURATION 


PRAGMA  INCLUDE  ('•A28006D1.TST") 

PRAGMA  INCLUDE  ( ''B28006E1 . TST" ) 

-2147483648 

2147483647 

2_147_483_648 

C 

-75  000.0 


$LESS_THAN_DURATION_BASE_FIRST  -13 1_073 . 0 
$LINE_TERMINATOR  »  ' 

$LOW_PRIORITy 
$MACHINE_CODE_STATEMENT 
$MACHINE  CODE  TYPE 


SMANTISSA_DOC 

$MAX_DIGITS 

$MAX_INT 

$MAX_INT_PLUS_1 

$MIN_INT 

$NAME 

$NAME_LIST 

$NAME_SPECIFICATI0N1 
$NAME_SPECIFICATION2 
$NAME  SPECIFICATION3 


0 

NULL; 

NO_SUCH_TYPE 

31 

15 

2147483647 
2_147_483_648 
-2147483648 
SHORT_SHORT_INTEGER 
RISC_ULTRIX 
/usr/var/ tinp/X2 12  OA 
/usr/var/tmp/X2 120B 
/usr/var/tnip/X3119A 
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$NEG_BASED_INT 

$NEW_MEM_SIZE 

$NEW_STOR_UNIT 

$NEW_SYS_NAME 

$PAGE_TERMINATOR 

$RECORD_DEFINITION 

$RECORD_NAME 

$TASK_SIZE 

$TASK_STORAGE_S I ZE 

$TICK 

$VARIABLE_ADDRESS 
$VARIABLE_ADDRESS 1 
$VARIABLE_ADDRESS  2 
$YOUR  PRAGMA 


16#FFFFFFFE# 

1_048_576 

8 

RISC_ULTRIX 
ASCII. LF  &  ASCII. FF 
RECORD  NULL;  END  RECORD; 
NO_SUCH_MACHINE_CODE_TYPE 
32 
0 

3.906  *  10.0**(-3) 
FCNDECL. VARIABLE_ADDRESS 
FCNDECL . VARIABLE_ADDRESS 1 
FCNDECL . VARIABLE_ADDRESS 2 
EXPORT  OBJECT 
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APPENDIX  B 


COMPILATION  SYSTEM  OPTIONS 

The  compiler  options  of  this  Ada  implementation,  as  described  in  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  compiler  documentation  and 
not  to  this  report. 

The  DEC  Ada  compiler  options  and  defaults  are  summarized  as  follows; 
o  -a 

Writes  a  data  analysis  file  containing  source  code  cross-referencing  and 
static  analysis  information.  By  default,  this  file  is  not  written. 

o  -A 

Specifies  the  program  library  context  to  be  used  for  the  compilation. The 
default  is  the  context  defined  by  environment  variable  ADALIB. 

o  -CO  or  -Cl 

Controls  whether  run-time  error  checking  is  suppressed.  (Use  of  -CO  is 
equivalent  to  giving  all  possible  suppress  pragmas  in  the  source 
program.)  The  default  is  -Cl  (error  checking  is  not  suppressed  except  by 
pragma) . 

o  -e 

Controls  the  number  of  error  level  diagnostics  that  are  allowed  within  a 
single  compilation  unit  before  the  compilation  is  aborted.  By  default 
the  error  limit  is  set  to  30  errors. 

o  -go,  -gl,  -g2,  -g3 

Controls  the  inclusion  of  debugging  symbol  table  information  in  the 
compiled  object  module.  The  default  is  to  include  partial  debugging 
symbol  table  information  (-gl) . 

o  -io,  -il,  -i2 

Controls  generic  processing.  By  default  (-il) ,  instances  are  compiled 
separately  from  the  unit  in  which  an  instantiation  occurred  unless  a 
pragma  INLINE_GENERIC  applies. -iO  disables  inline  expansion  of  generics. 
-i2  provides  maximal  inline  expansion  of  generics. 

o  -J 

Enables  maximal  inline  expansion  of  subprograms.  By  default,  subprograms 
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to  which  an  INLINE  pragma  applies  are  expanded  inline  under  certain 
conditions. 

o  -n 

Suppresses  updating  the  program  library  with  the  results  of  a 
compilation.  By  default,  the  library  is  updated  when  a  unit  compiles 
without  errors. 

o  -oO,  -ol,  -o2,  -o3,  -o4 

Controls  the  level  of  optimization  applied  in  producing  the  compiled 
code.  The  default  is  full  optimization  with  time  as  the  primary 
optimization  criterion  (-o4) . 

o  -QO,  -Q1 

With  -Ql,  the  compiler  makes  a  copy  of  the  source  file  in  the  program 
library  when  a  unit  is  successfully  compiled.  No  copy  is  made  under  -QO. 
The  default  is  -QO. 

o  -V 

Produces  a  source  listing.  A  source  listing  is  not  made  by  default, 
o  -w 

Suppresses  warning  messages.  By  default  warning  messages  are  not 
suppressed. 

o  -y 

Syntax  checks  the  specified  input  file.  By  default,  the  input  file  is 
compiled. 

o  -z 

Processes  the  input  file  as  a  detailed  design.  By  default,  the  input 
file  is  compiled. 
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LINKER  OPTIONS 


The  linker  options  of  this  Ada  implementation,  as  described  in  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  linker  documentation  and 
not  to  this  report. 

Linker  options 

Linking  was  done  using  the  DEC  Ada  aid  command.  The  aid  command  checks 
the  currency  of  all  units  in  the  execution  closure  of  a  program,  and,  if 
current,  invokes  Id,  the  standard  ULTRIX  linker.  The  default  aid  options 
were  used. 

The  DEC  Ada  aid  command  options  are  summarized  below: 
o  -A 

Specifies  the  program  library  context  to  be  used.  The  default  is  the 
context  defined  by  environment  variable  ADALIB. 

o  -j  elab_rtn 

Used  when  linking  Ada  code  with  a  non-Ada  main  program.  By  default,  the 
main  program  is  the  Ada  main  program  unit  named  as  an  argument  to  the  aid 
command . 

o  -L  Idflags 

Passes  'Idflags'  as  options  to  the  Id  linker.  By  default,  no  option 
flags  are  passed. 

o  -n 

Do  not  invoke  the  Id  linker.  By  default,  the  Id  linker  is  invoked.  If 
the  -n  option  is  specified,  the  aid  command  determines  if  all  units  are 
current  and  generates  the  object  file  needed  to  elaborate  library  units, 
but  does  not  do  the  actual  link. 

o  -o  out 

Names  the  output  file  'out'  rather  than  a. out. 
o  -r 

Retains  relocation  entries  in  the  output  object  file.  Relocation  entries 
must  be  saved  if  the  output  object  file  is  to  become  an  input  file  in  a 
subsequent  link.  By  default,  relocation  entries  are  not  retained. 

o  -u 
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Displays  the  units  that  are  to  be  linked.  By  default,  they  are  not 
displayed. 

o  -V 

Displays  the  Id  conunand  that  is  executed.  By  default,  it  is  not 
displayed. 
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APPENDIX  C 


APPENDIX  F  OF  THE  Ada  STANDARD 


The  only  allowed  implementation  dependencies  correspond  to 
implementation-dependent  pragmas,  to  certain  machine-dependent 
conventions  as  mentioned  in  Chapter  13  of  the  Ada  Standard,  and  to 
certain  allowed  restrictions  on  representation  clauses.  The 
implementation-dependent  characteristics  of  this  Ada  implementation, 
as  described  in  this  Appendix,  are  provided  by  the  customer.  Unless 
specifically  noted  otherwise,  references  in  this  Appendix  are  to 
compiler  documentation  and  not  to  this  report. 
Implementation-specific  portions  of  the  package  STANDARD,  which  are 
not  a  part  of  Appendix  F,  are: 

package  STANDARD  is 

type  SHORT_SHORT_INTEGER  is  range  -128.. 127; 

type  SHORT_INTEGER  is  range  -32768. .32768 ; 

type  INTEGER  is  range  -2147483648. .2147483647; 

type  FLOAT  is  digits  6  range  -3.40282E+38. .3.40282E+38; 

type  LONG_FLOAT  is  digits  15  range 

-1.7976931348623E+308. .1.7976931348623E+308; 

type  DURATION  is  delta  l.OE-4  range  -131072.0. .131071.9999; 


end  STANDARD; 
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The  following  are  attached: 

1 .  Predefined  language  pragmas . 

2 .  Implementation-dependent  characteristics 


Together  these  describe  implementation-dependent  characteristics  and 
contain  relevant  Appendix  F  material.  Note  that  both  are  extracted 
from  documentation  that  is  used  for  both  DEC  Ada  on  ULTRIX  systems  and 
VAX  Ada  on  VMS  systems.  Information  applies  to  both  ULTRIX  and  VMS 
unless  otherwise  stated;  information  that  only  applies  to  VAX  VMS 
systems  is  identified  with  "on  VMS  systems  only." 
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Predefined  Language  Pragmas 


'  1  This  annex  defines  the  pragmas  LIST  PAGE,  and  OPTIMIZE,  and  summarizes 
the  definitions  given  elsewhere  of  the  remaining  language-defined  pragmas. 

The  DEC  Ada  pragmas  IDENT  and  TITLE  are  also  defined  in  this  annev 


Pragma  Meaning 

AST_ENTKY  On  VMS  systems  only. 

Takes  the  simple  name  of  a  single 
entry  as  the  single  argument;  at  most 
one  AST_ENTRY  pragma  is  ^owed 
for  any  given  entry.  This  pragma 
must  be  used  in  combination  with  the 
AST_ENTRY  attribute,  and  is  only 
allowed  after  the  entry  declaration  and 
in  the  same  task  type  specification  or 
single  task  as  the  entry  to  which  it 
applies.  This  pragma  specifies  that  the 
given  entry  may  be  used  to  handle  a 
VMS  asynchronous  system  trap  (AST) 
resulting  finm  a  VMS  system  service 
call.  The  pragma  does  not  affect 
normal  use  of  the  entry  (see  9.12a). 

COAOION_OBJECT  Takes  an  internal  name  denoting 

an  object,  and  optionally  takes  an 
external  designator  (the  name  of  a 
linker  storage  area)  and  a  size  as 
arguments.  This  pragma  is  only 
allowed  at  the  place  of  a  declarative 
item,  and  must  apply  to  a  variable 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  package 
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specification.  The  variable  must 
have  a  size  that  is  known  at  compile 
time,  and  it  cannot  have  an  initi^ 
value.  This  pragma  is  not  allowed 
for  objects  declared  with  a  renaming 
declaration.This  pragma  enables  the 
shared  use  of  objects  that  are  stored  in 
overlaid  storage  areas  (see  13.9a.2.3). 

COMPON ENT_.ALIGNMEjNT  Takes  an  alignment  choice  and 

optionally  the  simple  name  of  an  array 
or  record  type  as  arguments.  If  a  type 
simple  name  is  specified,  the  pragma 
applies  only  to  that  type.  In  this  case, 
the  pragma  and  the  type  declaration 
must  both  occur  imme^tely  within 
the  same  declarative  part,  package 
specification,  or  task  specification; 
the  declaration  must  occur  before  the 
pragma.  The  position  of  the  pragma 
and  the  restrictions  on  the  named  type 
are  governed  by  the  same  rules  as 
those  for  a  representation  clause.  If  a 
type  simple  name  is  not  specified,  the 
pragma  affects  all  array  or  record  types 
declared  in  the  program  library,  except 
those  specified  in  a  pragma  PACK  or 
a  representation  clause  or  in  another 
pragma  COMPONENT JUJGNMENT. 
In  this  case,  the  pragma  is  only  allowed 
at  the  start  of  a  compilation,  before  the 
first  compilation  vmit  (if  any)  of  the 
compilation).  This  pragma  specifies 
the  kind  of  aligiunent  used  for  the 
components  of  the  array  or  record  types 
to  which  it  applies  (see  13.1a). 

2  CONTROLLED  Takes  the  simple  name  of  an  access 

type  as  the  single  argument.  This 
pragma  is  only  allowed  immediately 
within  the  declarative  part  or  package 
specification  that  contains  the 
declaration  of  the  access  type;  the 
declaration  must  occur  before  the 
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3  ELABORAIE 


EXPORT.EXCEPTION 


pragma.  This  pragma  is  not  allowed  for 
a  derived  type.  This  pragma  specifies 
that  automatic  storage  redamation 
must  not  be  performed  for  objects 
designated  by  values  of  the  access  type, 
except  upon  leaving  the  innermost 
blo^  statement,  subprogram  body,  or 
task  body  that  encloses  the  access  type 
declaration,  or  after  leaving  the  main 
program  (see  4.8). 

Takes  one  or  more  simple  names 
denoting  library  units  as  arguments. 
This  pragma  is  only  allowed 
immediately  after  the  context  clause 
of  a  compilation  unit  (before  the 
subsequent  library  unit  or  secondary 
unit).  Each  argument  must  be 
the  simple  name  of  a  library  unit 
mentioned  by  the  context  clause. 

This  pragma  specifies  that  the 
corresponding  library  unit  body 
must  be  elaborated  before  the 
given  compilation  unit.  If  the  given 
compilation  unit  is  a  subunit,  the 
library  unit  body  must  be  elaborated 
before  the  body  of  the  ancestor  library 
unit  of  the  subunit  (see  10.5). 

On  VMS  systems  only. 

Takes  an  internal  name  denoting 
an  exception,  and  optionally  takes 
an  external  designator  (the  name 
of  a  VMS  Linker  global  symbol), 
a  form  (ADA  or  VMS),  and  a  code 
(a  static  integer  expression  that  is 
interpreted  as  a  VAX  condition  code) 
as  arguments.  A  code  value  must  be 
specified  when  the  form  is  VMS  (the 
default  if  the  form  is  not  specified). 

This  pragma  is  only  allowed  at  the 
place  of  a  declarative  item,  and  must 
apply  to  an  exception  declared  by 
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an  earlier  declarative  item  of  the 
same  declarative  part  or  package 
specification;  it  is  not  allowed  for  an 
exception  declared  with  a  renaming 
declaration  or  for  an  exception  declared 
in  a  generic  unit.  This  pragma  permits 
an  Ada  exception  to  be  handled 
by  programs  written  in  other  \AX 
languages  (see  13.9a.3.2). 

EXPORT.FUNCnON  Takes  an  internal  name  denoting 

a  function,  and  optionally  takes  an 
external  designator  (the  name  of  a 
linker  global  symbol),  parameter  t3rpes, 
result  type,  parameter  mechanisms, 
and  result  mechanism  as  arguments. 
This  pragma  is  only  allowed  at  the 
place  of  a  declarative  item,  and 
must  apply  to  a  function  declared 
by  an  earlier  declarative  item  of  the 
same  declarative  part  or  package 
specification.  In  the  case  of  a  function 
declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the 
function  declaration  and  before 
any  subsequent  compilation  unit. 

This  pragma  is  not  allowed  for  a 
function  declared  with  a  renaming 
declaration,  and  it  is  not  allowed  for  a 
generic  function  (it  may  be  given  for 
a  generic  instantiation).  This  pragma 
permits  an  Ada  function  to  be  caUed 
fiom  a  program  written  in  another 
programming  language  (see  13.9a.l.3). 

EXPORT_OBJEC!T  Takes  an  internal  name  denoting  an 

object,  and  optionally  takes  an  extmnal 
designator  (the  name  of  a  linker  global 
symbol)  and  size  option  (a  linker 
absolute  global  symbol  that  will  be 
defined  in  the  object  module — useful 
on  VMS  systems  only)  as  arguments. 
This  pragma  is  only  allowed  at  the 
place  of  a  declarative  item,  and  must 
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apply  to  a  constant  or  a  variable 
declared  by  an  earlier  declarative 
item  of  the  same  declarative  part  or 
package  specification;  the  declaration 
must  occur  at  the  outermost  level  of  a 
library  package  specification  or  body. 
The  object  to  be  exported  must  have 
a  size  that  is  known  at  compile  time. 
This  pragma  is  not  allowed  for  objects 
declared  with  a  renaming  declaration, 
and  is  not  allowed  in  a  generic  unit. 
This  pragma  permits  an  Ada  object  to 
be  referred  to  by  a  routine  written  in 
another  programming  language  (see 
13.9a.2.2). 

EXPORT.PROCEDUKE  Takes  an  internal  name  denoting 

a  procedure,  and  optionally  takes 
an  external  designator  (the  name  of 
a  linker  ^obal  symbol),  parameter 
types,  and  parameter  mechanisms 
as  arguments.  This  pragma  is  only 
allowed  at  the  place  of  a  declarative 
item,  and  must  apply  to  a  procedure 
declared  by  an  earlier  declarative 
item  of  the  same  declarative  part  or 
package  specification.  In  the  case  of  a 
procedure  declared  as  a  compilation 
unit,  the  pragma  is  only  allowed 
after  the  procedure  declaration  and 
before  any  subsequent  compilation 
unit.  This  pragma  is  not  allowed  for 
a  procedure  declared  with  a  renaming 
declaration,  and  is  not  allowed  for  a 
generic  procedure  (it  may  be  given  for 
a  generic  instantiation).  This  pragma 
permits  an  Ada  routine  to  be  called 
from  a  program  written  in  another 
programming  language  (see  13.9a.l.3). 

EXPORT_VALUED_PROCEDURE  Takes  an  internal  name  denoting 
•  a  procedure,  and  optionally  takes 

an  external  designator  (the  name  of 
a  linker  global  symbol),  parameter 
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IDENT 


IMPORT 


types,  and  parameter  mechanisms 
as  arguments.  This  pragma  is  only 
allowed  at  the  place  of  a  declarative 
item,  and  must  apply  to  a  procedure 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  package 
specification.  In  the  case  of  a  procedure 
declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the 
procedure  declaration  and  before  any 
subsequent  compilation  unit.  The  first 
(or  only)  parameter  of  the  procedure 
must  be  of  mode  oat.  This  pragma  is 
not  allowed  for  a  procedure  declared 
with  a  renaming  declaration  and  is  not 
allowed  for  a  genetic  procedure  (it  may 
be  given  for  a  generic  instantiation). 
This  pragma  permits  an  Ada  procedure 
to  behave  as  a  function  that  lx>th 
returns  a  value  and  causes  side  effects 
on  its  parameters  when  it  is  called 
from  a  routine  written  in  another 
programming  language  (see  13.9a.l.3). 

Takes  a  string  literal  of  31  or  fewer 
characters  as  the  single  argument.  The 
pragma  IDENT  has  the  following  form: 

pragma  IDENT  (string_litaral) ; 

This  pragma  is  allowed  only  in 
the  outermost  declarative  part  or 
declarative  items  of  a  compilation  unit. 
The  given  string  is  used  to  identify 
the  object  module  associated  with  the 
compilation  unit  in  which  the  pragma 
IDES^  occurs. 

.EXCEPTION  On  VMS  systems  only. 

Takes  an  internal  name  denoting  an 
exception,  and  optionally  takes  an 
external  designator  (the  name  of  a 
VMS  Linker  global  symbol),  a  form 
(ADA  or  VMS),  and  a  code  (a  static 
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integer  expression  that  is  interpreted 
as  a  VAX  condition  code)  as  arguments. 
A  code  value  is  allowed  only  when  the 
form  is  VMS  (the  de&ult  if  the  form 
is  not  specified).  This  pragma  is  only 
allowed  at  the  place  of  a  declarative 
item,  and  must  apply  to  an  exception 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  package 
specification;  it  is  not  allowed  for  an 
exception  declared  with  a  renaming 
declaration.  This  pragma  permits  a 
non-Ada  exception  (most  notably,  a 
VKS.  condition)  to  be  handled  by  an 
Ada  program  (see  13.9a.3.1). 

IMPORT.FUNCmON  Takes  an  internal  name  denoting 

a  function,  and  optionally  takes  an 
external  designator  (the  name  of  a 
linker  global  symbol),  parameter  types, 
result  t3rpe,  parameter  mechanisms, 
and  resTxlt  mechanism  as  arguments. 
On  VMS  systems,  a  first  optional 
parameter  is  also  available  as  an 
argument.  The  pragma  INTERFACE 
must  be  used  with  this  pragma  (see 
13.9).  This  pragma  is  o^y  allowed  at 
the  place  of  a  declarative  item,  and 
must  apply  to  a  function  declared 
by  an  earlier  declarative  item  of  the 
same  declarative  part  or  package 
specification.  In  the  case  of  a  function 
declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the 
function  declaration  and  before  any 
subsequent  compilation  unit.  This 
pragma  is  allowed  for  a  function 
declared  with  a  renaming  declaration; 
it  is  not  allowed  for  a  generic  function 
or  a  generic  fimction  instantiation. 

This  pragma  permits  a  non-Ada 
routine  to  be  used  as  an  Ada  function 
(see  13.9a.l.l). 
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IMPORT_OBJECT  Takes  an  internal  name  denoting 

an  object,  and  optionally  takes  an 
external  designator  (the  name  of  a 
linker  global  symbol)  and  size  (a  linker 
absolute  global  symbol  that  'will  be 
defined  in  the  object  module — useful 
on  VMS  systems  only)  as  arguments. 
This  pragma  is  only  allowed  at  the 
place  of  a  declarative  item,  and 
must  apply  to  a  variable  declared 
by  an  earlier  declarative  item  of  the 
same  declarative  part  or  package 
specification.  The  variable  must  have 
a  size  that  is  known  at  compile  time, 
and  it  cannot  have  an  initial  value. 
This  pragma  is  not  allowed  for  objects 
declared  with  a  renaming  declaration. 
This  pragma  permits  storage  declared 
in  a  non-Ada  routine  to  be  referred  to 
by  an  Ada  program  (see  13.9a.2.1). 

IMPORT_PROCEDURE  Takes  an  internal  name  denoting 

a  procedure,  and  optionally  takes 
an  external  designator  (the  name  of 
a  linker  global  symbol),  parameter 
types,  and  parameter  mechanisms 
as  arguments.  On  VMS  systems, 
a  first  optional  parameter  is  also 
available  as  an  argument.  The  pragma 
INTERFACE  must  be  used  with  this 
pragma  (see  13.9).  This  pragma  is  only 
allowed  at  the  place  of  a  dedarative 
item,  and  must  apply  to  a  procedure 
declared  by  an  earlier  declarative 
item  of  the  same  dedarati-ve  part  or 
package  specification.  In  the  case  of  a 
procedure  declared  as  a  compilation 
unit,  the  pragma  is  only  allowed  after 
the  procedure  dedaration  and  before 
any  subsequent  compilation  unit.  This 
pragma  is  allowed  for  a  procedure 
declared  with  a  renaming  declaration; 
it  is  not  allowed  for  a  generic  procedure 
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or  a  generic  procedure  instantiation. 
This  pragma  permits  a  non-Ada  routine 
to  be  used  as  an  Ada  procedure 
(see  13.9a.l.l). 

IMPORT_VALUED_PROCEDURE  Takes  an  internal  name  doioting 

a  procedure,  and  optionally  takes 
an  external  designator  (the  name  of 
a  linker  global  symbol),  parameter 
types,  and  parameter  mechanisms 
as  arguments.  On  VMS  systems, 
a  first  optional  parameter  is  also 
available  as  an  argument.  The  pragma 
INTERFACE  must  be  used  with  this 
pragma  (see  13.9).  This  pragma  is  only 
allowed  at  the  place  of  a  declarative 
item,  and  must  apply  to  a  procedure 
declared  by  an  eariier  declarative  item 
of  the  same  declarative  part  or  package 
specification.  In  the  case  of  a  procedure 
declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the 
procedure  declaration  and  before  any 
subsequent  compilation  unit.  The  first 
(or  only)  parameter  of  the  procedure 
must  be  of  mode  out.  This  pragma 
is  allowed  for  a  procedure  declared 
with  a  renaming  declaration;  it  is  not 
allowed  for  a  genetic  procedure.  This 
pragma  permits  a  non-Ada  routine  that 
returns  a  value  and  causes  side  effects 
on  its  parameters  to  be  used  as  an  Ada 
procedure  (see  13.9a.l.l). 

*  INLINE  Takes  one  or  more  names  as 

arguments;  each  name  is  either  the 
name  of  a  subprogram  or  the  name  of 
a  generic  subprogram.  This  pragma 
is  only  allowed  at  the  place  of  a 
declarative  item  in  a  declarative  part 
or  package  specification,  or  after  a 
library  unit  in  a  compilation,  but  before 
any  subsequent  compilation  unit.  This 
pragma  specifies  that  the  subprogram 
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INLINE.GENERIC 


s  INTERFACE 


bodies  should  be  expanded  inline  at 
each  call  whenever  possible;  in  the  case 
of  a  generic  subprogram,  the  pragma 
applies  to  calls  of  its  instantiations 
(see  6.3^). 

Takes  one  or  more  names  as 
arguments;  each  name  is  either  the 
name  of  a  generic  declaration  or  the 
name  of  an  instance  of  a  generic 
declaration.  This  pragma  is  only 
allowed  at  the  place  of  a  declarative 
item  in  a  declarative  part  or  package 
specification,  or  after  a  library  unit 
in  a  compilation,  but  before  any 
subsequent  compilation  unit.  Each 
argument  must  be  the  simple  name 
of  a  generic  subprogram  or  package, 
or  a  (nongeneric)  subprogram  or 
package  that  is  an  instance  of  a  generic 
subprogram  or  package  declared  by 
an  earlier  declarative  item  of  the 
same  declarative  part  or  package 
specification.  This  pragma  specifies 
that  inline  expansion  of  the  generic 
body  is  desir^  for  eadi  instantiation 
of  the  named  generic  declarations  or 
of  the  particular  named  instances; 
the  pragma  does  not  apply  to  calls  of 
instances  of  generic  subprograms 
(see  12.1a). 

Takes  a  language  name  and  a 
subprogram  name  as  arguments.  This 
pragma  is  allowed  at  the  place  of  a 
declarative  item,  and  must  apply  in 
this  case  to  a  subprogram  declared 
by  an  earlier  declarative  item  of  the 
same  declarative  part  or  package 
specification.  This  pragma  is  also 
allowed  for  a  library  unit;  in  this  case 
the  pragma  must  appear  after  the 
subprogram  declaration,  and  before 
any  subsequent  compilation  unit.  This 
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pragma  specifies  the  other  language 
(and  thereby  the  calling  conventions) 
and  informs  the  compiler  that  an 
object  module  will  be  supplied  for  the 
corresponding  subprogram  (see  13.9). 

In  DEC  Ada,  the  pragma  INTERFACE 
is  required  in  combination  with  the 
pragmas  IMPORT_FUN(7nON, 
IMPORT_PROCEDURE.  and 

import_valued_procedure 

when  any  of  those  pragmas  are  used 
(see  13.9a.l). 

«  LIST  Takes  one  of  the  identifiers  ON  or 

OFF  as  the  single  argument.  This 
pragma  is  allowed  anywhere  a  pragma 
is  allowed.  It  specifies  that  listing  of 
the  compilation  is  to  be  continued  or 
suspended  until  a  LIST  pragma  with 
the  opposite  argument  is  given  within 
the  same  compilation.  The  pragma 
itself  is  always  listed  if  the  compiler  is 
produdz^  a  listing. 

LONG_FLOAT  On  VMS  systems  only. 

Takes  either  D_FLOAT  or  G_FLOAT 
as  the  single  argument  The  default 
is  G_FLOAT.  This  pragma  is  only 
allowed  at  the  start  of  a  compilation, 
before  the  first  compilation  unit 
(if  any)  of  the  compilation.It  specifies 
the  choice  of  representation  to  be  used 
for  the  predefined  type  LONG_FLOAT 
in  the  package  STAI^ARD,  and  for 
floating  point  type  declarations  with 
digits  specified  in  the  range  7  ..  15 
(see  3.5.7a). 

MAIN_ST0RAGE  Takes  one  or  two  nonnegative  static 

simple  expressions  of  some  integer  t3rpe 
as  arguments.  This  pragma  is  only 
allowed  in  the  outermost  declarative 
part  of  a  library  subprogram;  at  most 
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7  MEMORY.SIZE 


OPTIMIZE 


PACK 


one  such  pragma  is  allowed  in  a  library 
subprogram.  It  bas  an  effect  only  when 
the  subprogram  to  which  it  applies  is 
used  as  a  main  program.  This  pragma 
causes  a  fixed-size  stack  to  be  created 
for  a  main  task  (the  task  associated 
with  a  main  program),  and  determines 
the  number  of  storage  units  (bytes) 
to  be  allocated  for  the  stack  working 
storage  area  or  guard  pages  or  both. 
The  value  specified  for  either  or  both 
the  working  storage  area  and  guard 
pages  is  rounded  up  to  an  appropriate 
boundary.  A  value  of  zero  for  the 
working  storage  area  results  in  the  use 
of  a  default  size;  a  value  of  zero  for 
the  guard  pages  results  in  no  guard 
storage.  A  negative  value  for  either 
working  storage  or  guard  pages  causes 
the  pragma  to  be  ignored  (see  13.2b). 

Takes  a  numeric  literal  as  the  single 
argument.  This  pragma  is  only  aUowed 
at  the  start  of  a  compilation,  before  the 
first  compilation  unit  (if  any)  of  the 
compilation.  The  effect  of  this  pragma 
is  to  use  the  value  of  the  specified 
numeric  literal  for  the  deflation  of  the 
named  number  MEMORY.SIZE 
(see  13.7). 

Takes  one  of  the  identifiers  TIME 
or  SPACE  as  the  single  argument. 

This  pragma  is  only  allowed  within  a 
declarative  part  and  it  applies  to  the 
block  or  body  enclosing  tiie  declarative 
part.  It  specifies  whether  time  or  space 
is  the  primary  optimization  criterion. 

In  DEC  Ada,  this  pragma  is  only 
allowed  immediately  within  a 
declarative  part  of  a  body  declaration. 

Takes  the  simple  name  of  a  record  or 
array  type  as  the  single  argument.  The 
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10  PAGE 


PRIORITY 


PSECT.OBJECT 


SHARED 


allowed  positions  for  this  pragma,  and 
the  restrictions  on  the  named  type, 
are  governed  by  the  same  rules  as  for 
a  representation  clause.  The  pragma 
specifies  that  storage  minimization 
should  be  the  main  criterion  when 
selecting  the  representation  of  the 
given  type  (see  13.1). 

This  pragma  has  no  argument,  and  is 
allowed  anywhere  a  pragma  is  allowed. 
It  specifies  that  the  program  text  which 
follows  the  pragma  should  start  on  a 
new  page  (if  the  compiler  is  currently 
producing  a  listing). 

Takes  a  static  expression  of  the 
pieddSned  integer  subtype  PRIORITY 
as  the  single  argument.  This  pragma  is 
only  allowed  within  the  specification  of 
a  task  unit  or  immediately  within  the 
outermost  declarative  part  of  a  main 
program.  It  specifies  the  priority  of  the 
task  (or  tasks  of  the  task  type)  or  the 
priority  of  the  main  program  (see  9.8). 

On  VMS  systems  only. 

Has  the  same  syntax  and  the  same 
effect  as  the  pragma  COMMON. 
OBJECT  (see  13.9a.2.3). 

Takes  the  simple  name  of  a  variable  as 
the  single  argument.  This  pragma  is 
allowed  only  for  a  variable  declared  by 
an  object  declaration  and  whose  type 
is  a  scalar  or  access  type;  the  variable 
declaration  and  the  pragma  must 
both  occur  (in  this  order)  immediately 
within  the  same  declarative  part  or 
package  specification.  This  pragma 
specifies  that  every  read  or  update  of 
the  variable  is  a  synchronization  point 
for  that  variable.  An  implementation 
must  restrict  the  objects  for  which 
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this  pragma  is  allowed  to  objects 
for  which  each  of  direct  reading  and 
direct  updating  is  implemented  as  an 
indivisible  operation  (see  9.11). 

SHARE_6EINSRIC  On  VMS  systems  only. 

Takes  one  or  more  names  as 
arguments;  each  name  is  either  the 
name  of  a  generic  declaration  or  the 
name  a£  an  instance  of  a  generic 
declaration.  This  pragma  is  only 
allowed  at  the  place  of  a  declarative 
item  in  a  declarative  part  or  package 
specification,  or  after  a  library  unit  in  a 
compilation,  but  before  any  subsequent 
compilation  unit.  Each  argiunent 
either  must  be  the  simple  name  of  a 
generic  subprogram  or  package,  or  it 
must  be  a  (nongeneiic)  subprogram 
or  package  that  is  an  instance  of  a 
generic  subprogram  or  package.  If  the 
argument  is  an  instance  of  a  generic 
subprogram  or  package,  then  it  must 
be  declared  by  an  earlier  declarative 
item  of  the  same  declarative  part  or 
package  specification.  This  pragma 
specifies  that  generic  code  sharing  is 
desired  for  each  instantiation  of  the 
named  generic  declarations  or  of  the 
particular  named  instances  (see  12.1b). 

13  STORAGE_UNIT  Takes  a  numeric  literal  as  the  single 

argument.  This  pragma  is  only  allowed 
at  the  start  of  a  compilation,  l^fore  the 
first  compilation  unit  (if  any)  of  the 
compilation.  The  effect  of  this  pragma 
is  to  use  the  value  of  the  specified 
niimeric  literal  for  the  definition  of  the 
named  number  STORAGE  UNIT 
(see  13.7). 

In  DEC  Ada,  the  only  argument 
allowed  for  this  pragma  is  8  (bits). 
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'  SUPPRESS.ALL 


SYSTEM.NAME 


Takes  as  arguments  the  identifier 
of  a  che<^  and  optionally  also  the 
name  of  either  an  object,  a  type  or 
subtype,  a  subprogram,  a  task  unit,  or 
a  generic  unit.  'Hus  pragma  is  only 
aUowed  either  immediately  within  a 
declarative  part  or  immediately  within 
a  package  specification.  In  the  latter 
case,  the  only  allowed  form  is  with  a 
name  that  denotes  an  entity  (or  several 
overloaded  subprograms)  declared 
immediately  within  the  package 
specification.  The  permission  to  omit 
the  given  check  extends  firom  the 
place  of  the  pragma  to  the  end  of  the 
declarative  region  associated  with  the 
innermost  enclosing  block  statement  or 
program  unit.  For  a  pragma  given  in  a 
package  spedfication,  the  permission 
extends  to  the  end  of  the  scope  of  the 
named  entity. 

If  the  pragma  includes  a  name,  the 
permission  to  omit  the  given  check 
is  further  restricted:  it  is  given  only 
for  operations  on  the  named  object 
or  on  all  objects  of  the  base  type  of  a 
named  type  or  sribtype;  for  calls  of  a 
named  subprogram;  for  activations  of 
tasks  of  the  named  task  type;  or  for 
instantiations  of  the  given  generic  unit 
(see  11.7). 

This  pragma  has  no  argument  and  is 
only  allowed  following  a  compilation 
unit.  This  pragma  specifies  that 
all  run-time  checks  in  the  unit  are 
suppressed  (see  11.7). 

Takes  an  enumeration  literal  as  the 
single  argument.  This  pragma  is  only 
allowed  at  the  start  of  a  compilation, 
before  the  first  compilation  unit 
(if  any)  of  the  compilation.  The  effect  of 
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TASK_STORAGE 


TIME.SLICE 


this  pragma  is  to  use  the  enumeration 
literal  with  the  specified  identifier 
for  the  definition  of  the  constant 
SYS1EM_NAME.  This  pragma  is 
only  allowed  if  the  specified  identifier 
corresponds  to  one  of  the  literals  of  the 
t3rpe  NAME  declared  in  the  package 
SYSTEM  (see  13.7). 

Takes  the  simple  name  of  a  task 
type  and  a  static  expression  of  some 
integer  t3rpe  as  arguments.  This 
pragma  is  allowed  anywhere  that  a 
task  storage  specification  is  allowed; 
that  is,  the  declaration  of  the  task 
type  to  which  the  pragma  applies  and 
the  pragma  must  both  occur  (in  this 
order)  immediately  within  the  same 
declarative  part,  package  specification, 
or  task  specification.  The  effect  of 
this  pragma  is  to  use  the  value  of  the 
expression  as  the  number  of  storage 
units  (bytes)  to  be  allocated  as  guard 
storage.  The  value  is  rounded  up  to 
an  appropriate  boundary.  A  negative 
value  causes  the  pragma  to  be  ignored. 
A  zero  value  has  system-specific 
resiilts:  on  VMS  systems,  a  value 
of  zero  results  in  no  guard  storage; 
on  ULTKIX  systems,  a  value  of  zero 
results  in  a  minimal  guard  area  (see 
13.2a). 

On  VMS  systems  only. 

Takes  a  static  expression  of  the 
predefined  fixed  point  type  DURATION 
(in  the  package  STANDARD)  as  the 
single  argument.  This  pragma  is  only 
allowed  in  the  outermost  declarative 
part  of  a  library  subprogram,  and  at 
most  one  such  pragma  is  allowed  in  a 
library  subprogram.  It  has  an  effect 
only  when  the  subprogram  to  which 
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it  applies  is  used  as  a  main  program. 
This  pragma  causes  the  task  scheduler 
to  limit  the  amount  of  continuous 
execution  time  given  to  a  task 
(see  9.8a). 

TITLE  Takes  a  title  or  a  subtitle  string,  or 

both,  as  arguments.  The  pragma 
TITLE  has  the  following  form: 

pragme  TITLE  (titling-option 
(, titling-option] ) ; 

titling-option 

(TITLE  ■>]  atring_lit«r«l 
I  (SUBTITLE  ■■>]  strlng_lit*ral 

This  pragma  is  allowed  anywhere  a 
pragma  is  allowed;  the  given  strings 
supersede  the  de&ult  title  and/or 
STibtitle  portions  of  a  compilation 
listing. 

VOLATILE  Takes  the  simple  name  of  a  variable 

as  the  single  argument.  This  pragma 
is  only  allowed  for  a  variable  declared 
by  an  object  declaration.  The  variable 
declaration  and  the  pragma  must 
both  occur  (in  this  order)  immediately 
within  the  same  declarative  part  or 
package  specification.  The  pragma 
must  appear  before  any  occurrence  of 
the  name  of  the  variable  other  than 
in  an  address  clause  or  in  one  of  the 
DEC  Ada  pragmas  IMPORT_OBJECT, 
EXPORT.OBJECTT,  COMMON. 
OBJECrr,  or  PSECT.OBJECT.  The 
variable  cannot  be  declared  by  a 
renaming  declaration.  The  pragma 
VOLATILE  spedfies  that  the  variable 
may  be  modified  asynchronously.  This 
pragma  instructs  the  compiler  to  obtain 
the  value  of  a  variable  from  memory 
each  time  it  is  used  (see  9.11). 
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_  Note  _ 

This  appendix  is  not  part  of  the  standard  definition  of  the  Ada 
programming  language. 


This  appendix  stimmaiizes  the  implementation-dependent  characteristics  of 
DEC  /ula  by  presenting  the  following: 

*  Lists  of  the  DEC  Ada  pragmas  and  attributes. 

*  The  specification  of  the  package  SYSTEM. 

*  The  restrictions  on  representation  clauses  and  unchecked  type  conversions. 

*  The  conventions  for  names  denoting  implementation-dependent 
components  in  record  representation  clauses. 

*  The  interpretation  of  expressions  in  address  clauses. 

*  The  implementation-dependent  characteristics  of  the  input-output 
packages. 

*  Other  implementation-dependent  characteristics. 

F.1  Implementation-Dependent  Pragmas 

DEC  Ada  provides  the  following  pragmas,  which  are  defined  elsewhere  in  the 
text.  In  addition,  DEC  Ada  restricts  the  predefined  language  pragmas  INLINE 
and  INTERFACE.  See  Annex  B  for  a  descriptive  pragma  summary. 
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Pragma 

DEC  Ada 
systams 
on  which  It 
applies  Section 

AST_ENTBy 

VMS 

9.12a 

COMMON.OBJECT 

All 

13.9a.2.3 

COMPONENTjUJGNMENT 

All 

13.1a 

EXPORT_EXCEPnON 

VMS 

13.9a.3.2 

EXPOBT.PUNCnON 

All 

13.9a.l.3 

EXPORT.OBJECT 

All 

13.9a.2.2 

EXPORT_PROCEDURE 

All 

13.9a.l.3 

EXPORT_VALUED.PROCEDURE 

All 

13.9a.l.3 

IDENT 

All 

AzmexB 

IMPORT.EXCEPnON 

VMS 

13.9a.3.1 

IMPORT_FUNCnON 

All 

13.9a.Ll 

IMPORT.OBJECT 

All 

13.9a.2.1 

IMPORT.PROCEDURE 

All 

13.9a.l.l 

IMPORT_VALUED_PROCEDURE 

AU 

13.9a.l.l 

INLINE_GENERIC 

All 

12.1a 

LONG_FLOAT 

VMS 

3.5.7a 

MAIN.STORAGE 

All 

13.2b 

PSECT.OBJECT 

VMS 

13.9a.2.3 

SHARE.GENERIC 

All 

12.1b 

SUPPRESS JUX 

All 

11.7 

TASR.STORAGE 

All 

13.2a 

TIME.SLICE 

AU 

9.8a 

TITLE 

AU 

Annex  B 

VOLATILE 

AU 

9.U 

F.2  Implementation-Dependent  Attributes 

DEC  Ada  provides  the  following  attributes,  which  are  defined  elsewhere  in  the 
text.  See  Annex  A  for  a  descriptive  attribute  summary. 


F.2  Implementation-Oapendent  Attributes 
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Attribute 

DEC  Ada 
syatams 
on  which  it 
applies  Section 

AST.ENTRy 

VMS 

9.12a 

BIT 

An 

13.7.2 

MACHINE.SIZE 

An 

13.7.2 

NULL.PARAMETER 

VMS 

13.9a.l.2 

TYPE.CLASS 

An 

13.7a.2 

F.3  Specification  of  the  Package  System 

DEC  Ada  provides  a  system-specific  version  of  the  packaj'e  SYSTEM  for 
each  system  on  which  it  is  supported.  The  individual  package  SYSTEM 
specifications  appear  in  the  following  sections. 


F.3.1  The  Package  System  on  VMS  Systems 

package  SYSTEM  is 

type  NAME  is  (VAX_VMS,  VAXELN)  ; 
for  NAME  use  (1,  2); 

SYSTEM  NAME 
STORA^  UNIT 
MEMORY  SIZE 
MAX  INT 

min“int 
max“digits 

MAX~MANTISSA 
FINE  DELTA 

ticx“ 

subtype  PRIORITY  is  INTEGER  range  0  . .  IS ; 

"  Address  type 


:  constant  NAME  VAX_VMS; 
:  constant  8;  ~ 

:  constant  :■  2**31-1; 

:  constant 

:  constant  :■  -(2**31); 

:  constant  33; 

:  constant  :>  31; 

:  constant  :■  2.0** (-31); 

:  constant  10. 0** (-2); 


type  ADDRESS  is  private; 

ADDRESS_ZERO  ;  constant  ADDRESS; 

function  "f*  (LEFT  :  ADDRESS;  RIGHT  :  INTEGER)  return  ADDRESS; 

function  "f"  (LEFT  :  INTEGER;  RIGHT  :  ADDRESS)  return  ADDRESS; 

function  (LEFT  :  ADDRESS;  RIGHT  :  ADDRESS)  return  INTEGER; 

function  (LEFT  :  ADDRESS;  RIGHT  :  INTEGER)  return  ADDRESS ; 
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..  function  (LEFT,  RIGHT  :  ADDRESS)  nturn  BOOLEAN; 

—  function  "/>”  (lEFT,  RIGHT  :  ADDRESS)  rntuzn  BOOLEAN; 

function  "<"  (LEFT,  RIGHT  :  ADDRESS)  raturn  BOOLEAN; 

function  "<>”  (I£FT,  RIGHT  :  ADDRESS)  ratuzn  BOOLEAN; 

function  ">"  (LEFT,  RIGHT  :  ADDRESS)  ratuza  BOOLEAN; 

function  (LEFT,  RIGHT  :  ADDRESS)  zatuzn  BOOLEAN; 

—  Note  that  because  ADDRESS  is  a  private  type 

—  the  functions  and  ”/■*  are  already  available  and 

—  do  not  have  to  be  ejq>licitl7  defined 

ganazic 

type  TARGET  is  private; 

function  FETCE_FROM_ADDRESS  (A  :  ADDRESS)  return  TARGET; 
generic 

type  TARGET  is  private; 

procedure  ASSIGN_TO_ADDRESS  (A  :  ADDRESS;  T  ;  TARGET); 

--  DEC  Ada  floating  point  type  declarations  for  the  VAX 

—  hardware  floating  point  data  types 

F_FL0AT  is  isgileiiientaCion_defined; 

D~FLOAT  is  ioplesienCation^defined; 
type  GJEXOAT  is  isgilesMotation^defined; 
type  H~FL0AT  is  ispleoentation^definad; 

type  TTFS  CLASS  is  (TTFE  CLASS  ENUMERATION, 
ttpe“class“integer, 
t»e"class“fixed  point, 

TTPE'CLASS-FLOATnfG  POINT, 

ttpe"class~arrat, 
ttpe“class~record , 

T5EE"CLASS”ACCESS, 

ttpe“class”task, 

TTPE~CLASS_ADDRESS) ; 

—  AST  handler  type 

type  AST_HANDL£R  is  liaitad  private; 

NO_AST_aANDLER  :  constant  AST_HANDLER; 

—  Non-Ada  exception 
NON_ADA_ERROR  ;  ezcaption; 

—  Hardware-oriented  types  and  functions 

type  BIT  ARRAT  is  array  (INTEGER  range  <>)  of  BOOLEAN 
pragma  PAdc(BIT_ARRAT)  ; 

subtype  BIT  ARRAY  8  is  BIT  ARRAT  (0  . .  7) ; 

subtype  BIT~ARRAy~l6  is  BIT”aRRAI  (0  . .  15) ; 
subtype  BIT“aRRAY~32  is  BIT'ARRAI  (0  . .  31) ; 
subtype  BIT~ARRAT~64  is  BIT~ARRAT  (0  . .  63) ; 


F.3.1  The  Package  System  on  VMS  Systems 


lmplementatlon*Dependent  Characteristics 


fsf  DNSIGNED  BXTE  is  ruga  0  ..  255; 
for  DNSZGNED~BrTE'SZZ£  usa  8; 

fnactioa  "not”  (LEFT  :  OMSZQIEO  BYTE)  ratvn  ORSZGBEO  BYTE; 

fnaetioa  "and"  (LEFT,  RZGBT  :  ONSZtaiEO^BYTE)  rattua  UMSZ6I1E0~BYTE; 

fnnetion  "or"  (LEFT,  RZGBT  ;  UNSZGNED~BYTE)  ratara  DNSZG))ED~BYTE; 

fnactioa  *ror*  (LEFT,  RZGBT  :  UNSZGNEO~BYTE)  catnza  miSZGHEO^B^^; 

fnactioa  TO  tmsZGMED  BYTE  (X  :  BZT  ARRAY  8)  catnxa  ONSZGMEO  BYTE; 
fnactioa  T0~BZT_ARRAY_8  (X  :  tJNSZGfeD_BYTC)  ratnra  BZT_ARRAY_8; 

tYpa  aiISZGNEl)_BYTE_ARRAY  it  am;  (ZNTEGER  raaga  <>)  of  nNSZGIlED_BYTE; 

tYpa  UNSZGNEI}  HORD  is  caaga  0  ..  65535; 
for  ONSZGMEO JTORO'SZZE  nsa  16; 

fnactioa  "not”  (LEFT  ;  ONSZGNEO  NORO)  catnza  ONSZGMEO  NORO; 

fnactioa  "and”  (LEFT,  RZGBT  :  ONSZGNEO~ NORO)  catnza  ONSZGMEO~NORO; 

fnactioa  "or"  (LEFT,  RZGBT  :  OMSZGNEO~HORO)  catnza  ONSZGMEO~NORO; 

fnactioa  "xoc"  (LEFT,  RZGBT  :  OMSZGNEO~NORO)  catuza  ONSZGNEO~NORO; 

fnactioa  TO  ONSZGMEO  NORO  (X  :  BZT  ARRAY  16)  catnza  ONSZGNEO  NORO; 
function  T02BZT_ARRAy_16  (X  :  ONSZQIEO_HORO)  ratnra  BZT_ARRAY_16; 

typa  ONSZGNEO_NORO_ARRAY  is  array  (ZNTEGER  ranga  <>)  of  ONSZGNEO_NORO; 

typa  ONSZGNEO  LOMGNORO  is  caaga  MZM  ZNT  . .  MAX_ZNT; 
for  ONSZGNEO_LbNGWORO'SZZE  nsa  32; 

fnactioa  "not"  (LEFT  :  ONSZGNEO  LONGWORO)  ratnra  ONSZGNEO  LONGWORO; 

function  "and"  (LEFT,  RZGBT  ;  ONSZGNEO~LONGWORO)  ratnra  ONSZGNEO~LONGWORO; 

function  "or"  (LEFT,  RZGBT  ;  ONSZGNEO~LONGWORO)  ratuza  ONSZGNEO~LONGHORO ; 

fnactioa  "xor"  (LEFT,  RZGBT  :  ONSZGNEO~LONGWORO)  ratnra  ONSZGNEO~LONGHORO; 

fnnetion  TO_ONSZGNEO_LONGWORO  (X  :  BZT_ARRAY_32) 
ratnm  ONSZGNEO  LONGWORO;  ~  ~ 

fnnetion  TO_BZT_AI^Y_32  (X  :  ONSZGNEO_LONGWORO)  ratnm  BZT_ARRAT_32; 

typa  ONSZGNEO  LONGWORO  ARRAY  is 

array  (ZNTEGER  ranga  <>)  of  ONSZGNEO_LONGWORO; 

type  ONSZGNEO  QOAOWORO  is  record 
LO  :  ONSZGNEO  LONGWORO; 

LI  :  ONSZGMEO~LONGWORO; 
and  record;  ~ 

for  ONSZGNEO_QOAOWORO'SZZE  nsa  64; 

fnnetion  "not"  (LEFT  :  ONSZGNEO  QOAOWORO)  ratnm  ONSZGMEO  QOAOWORO; 

function  "and"  (LEFT,  RZGBT  :  ONSZ6NEO~QOADNORO)  mtnm  ONSZGNEO~QOAOWORO; 

fnaetioa  "or"  (LEFT,  RZGBT  :  ONSZGNEO~QOADWORO)  ratnm  ONSZGNEO~QOAOWORO; 

function  "r.or"  (LEFT,  RZGBT  :  ONSZGMEO~QOAOWORO)  mtnm  ONSZGNEO~QOAOWORO; 

function  TO  ONSZGNEO  QOAOWORO  (X  :  BZT  ARRAY_64) 
return  ONSZGNEO  QOAOWORO; 

function  TO_BZT_ARRAy_64  (X  :  ONSZGNEO_QOADWORO)  mtnm  BZT_ARRAY_64  ; 

typa  ONSZGNEO  QOAOWORO  ARRAY  is 

array  (ZNTEGER  range  <>)  of  ONSZGNEO_QOAOWORO ; 
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funetioa  TO  ADOBESS  (X  :  ISTEGER)  rctnza  ADOKESS; 

fnnetioa  TO~ADDBESS  (X  :  UIISIGMED_LON6fiORD)  ratnxa  AOORESS; 

fnaetion  TO~AOORESS  (X  :  iiainrs^_integet)  xatoza  ADDRESS; 

£uaetioa  TO  INTEGER  (X  :  ADDRESS)  ratoxn  INTEGER; 

fnaetion  TO~nNSIGNED_LONGNORD  (X  :  ADDRESS)  ratnxa  nNSI6NED_L0NGtl0RD; 

fnaetion  TO_DNSIGNED_LONGRORD  (X  :  AST_HANDLER)  ratnxa  0NSIGNED_L0NGN0RD; 

—  Conventional  nastas  for  static  subtypes  of  type  UNSIGNED_LONGfX>RD 

snbtypa  ONSIGNEO  1  is  UNSIGNED  L0N6R0RD  raaga  0  ..2**  1-1; 

snbtypa  DNSIGNED~2  is  ONSIGNED'lONGNORD  raaga  0  ..  2**  2-1; 

snbtypa  nNSIGNED~3  is  UNSIGNED~L0N6R0RD  raaga  0  ..  2**  3-1; 

snbtypa  UNSIGNED~4  is  UNSIGNED~LON60ORD  raaga  0  ..  2**  4-1; 

snbtypa  0NSIGNED''5  is  nNSIGNED~LONGNORD  raaga  0  ..  2**  5-1; 

snbtypa  UNSIGNED'S  is  ONSIGNED~U}NGNORD  raaga  0  . .  2**  $-1; 

snbtypa  UNSIGNED~7  is  UNSIGNED'lONGNORD  raaga  0  ..  2**  7-1; 

snbtypa  UNSIGNED~8  is  UNSIGNED^LONGNORD  raaga  0  . .  2**  8-1; 

snbtypa  UNSIGNED"9  is  UNSIGNED"u)KG»ORD  raaga  0  . .  2**  9-1; 

snbtypa  UNSIGNED~10  is  UNSIGNED^LONGHORD  raaga  0  ..  2**10-1; 

snbtypa  UNSIGNEO'll  is  UNSIGNED~LONGNORD  raaga  0  ..  2**11-1; 

snbtypa  0NSIGNED~12  is  UNSIGNE-o'‘l.ONGNORD  raaga  0  ..  2**12-1; 

snbtypa  UNSIGNED'*13  is  ONSIGNED''i.ONGNORD  raaga  0  ..  2**13-1; 

snbtypa  UNSIGNED~14  is  UNSIGNED^LONGNORD  raaga  0  ..  2**14-1; 

snbtypa  UNSIGNED~15  is  DNSIGNED~IX}NGNORD  raaga  0  ..  2**15-1; 

snbtypa  UNSIGNED~16  is  DNSIGNED~I,ONGHORD  raaga  0  ..  2**16-1; 

snbtypa  UNSIGNED~17  is  ONSIGNED~LON6RORD  raaga  0  ..  2**17-1; 

snbtypa  UNSIGNED~18  is  UNSIGMED~LONGHORD  raaga  0  . .  2**18-1; 

snbtypa  UNSIGNED~19  is  UNSIGNED  LONGNORD  raaga  0  ..  2**19-1; 

snbtypa  UNSIGNED~20  is  UNSIGNED'lONGNORD  raaga  0  ..  2**20-l; 

snbtypa  UNSIGNED~21  is  UNSIGNED~LONGNORD  raaga  0  ..  2**21-1; 

snbtypa  UNSIGNED~22  is  UNSIGNED~LONQ«ORD  raaga  0  ..  2**22-l; 

snbtypa  UNSIGNED~23  is  UNSIG}:ED~1.0NGNORD  raaga  0  . .  2**23-l; 

snbtypa  UNSIGNED~24  is  UNSIGNED~LONGNORD  raaga  0  ..  2**24-l; 

snbtypa  UNSIGNED~25  is  UNSIGNED~LONGHORD  raaga  0  ..  2**25-l; 

snbtypa  UNSIGNED~26  is  UNSIGNED'longNORD  raaga  0  ..  2**26-l; 

snbtypa  DNSIGNED“27  is  UNSIGNED“lONGWORD  raaga  0  ..  2**27-l; 

snbtypa  UNSIGNED~28  is  UNSIGNED~LONGRORD  raaga  0  ..  2**28-l; 

snbtypa  UNSIGNEO~29  is  UNSIGNED~I.ONG«ORD  raaga  0  ..  2**29-l; 

snbtypa  UNSIGNED~30  is  UNSIGNED~l.ONGIf0RD  raaga  0  ..  2**30-l; 

snbtypa  UNSIGNED~31  is  UNSIGNED~L0NGN0RD  raaga  0  ..  2**31-1; 

—  Function  for  obtaining  global  symbol  values 

fnaetion  IMPORT_VALUE  (STMBOL  :  STRING)  ratnxa  UNSIGNED_I,ONGNORD; 

—  VAX  device  and  process  register  operations 

fnaetion  READ  REGISTER  (SOURCE  :  UNSIGNEO_BTTE) 
return  UNSIOIED  BTTE; 

fnaetion  READ  REGISTER  (SOURCE  ;  UNSIGNED  WORD) 
rotnxB  UNSI^D  HORD; 

funetioa  READ  REGISTER  (SOURCE  :  UNSIGNED  LONGNORD) 
ratnxa  UNSIGNED  LONGHORD; 
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procadnn  NRZIE  REGISTER  (SOURCE  :  UNSIGNED  BYTE; 

TARGET  :  ont  UNSI^D  BYTE); 
procedon  WRITE  REGISTER  (SOURCE  :  UNSIGNED  NORD; 

TARGET  :  oat  UNSIOIED  WORD)  ; 
pxoeadnra  WRITE  REGISTER (SOURCE  :  UNSIGNED  LONGWORD; 

TARGET  :  oot  ONSiaiED_LONGWORD)  ; 

fonction  MF?R  (R£G_NUMBER  :  INTEGER)  ratorn  UNSIGNED_IiONGWORD; 
pcoeadur*  MTPR  (REG  NUMBER  :  INTEGER; 

SOURCE  :  UNSIGNEO_LONGNORD) ; 

—  VAX  interlocJced-instniction  procedures 

procedure  CLEAR  INTERLOCKED  (BIT  :  in  out  BOOLEAN ; 

OLD  VALUE  :  oat  BOOLEAN); 

proeedore  SET  INTERLOCKED  (BIT~  ;  in  oat  BOOLEAN; 

OLD_VALOE  :  oat  BOOLEAN); 

type  ALIGNEOJTORD  is 
record  ” 

VALUE  ;  SHORT_INTEGER; 
end  record;  ~ 
for  ALIGNED_WORO  use 
record  ~ 
et  nod  2; 
end  record; 

procedure  AOD_INTERLOCKEO  (ADDEND  :  in  SHORT_INTEGER; 

~  AUGEND  :  in  out  ALIGNED  WORD; 

SIGN  ;  out  INTEGERf; 

type  INSQ  STATUS  is  (OK  NOT  FIRST,  FAIL  NO  LOCK,  OK  FIRST) ; 
type  REMQ~STATUS  is  (OK~NOT~EMPTY,  FAIL~NO“lOCK, 

OKjaCTY,  FAIL_WAS~EIffiTY)  ; 

procedure  INSQHI  (ITEM  :  in  ADDRESS; 

HEADER  :  in  ADDRESS; 

STATUS  :  out  INSQ_STATUS) ; 

procedure  REMQHI  (HEADER  :  in  ADDRESS ; 

ITEM  :  out  ADDRESS; 

STATUS  :  out  REMQ_STATUS) ; 

procedure  INSQTI  (ITEM  :  in  ADDRESS ; 

HEADER  :  in  ADDRESS ; 

STATUS  :  out  INSQ_STATUS) ; 

procedure  REMQTI  (HEADER  :  in  ADDRESS; 

ITEM  :  out  ADDRESS; 

STATUS  :  out  REMQ_STATUS) ; 

private 

—  Mot  shown 
end  SYSTEM; 
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F.3.2  The  Package  System  on  ULTRIX  Systems 

padcag*  S7S7EM  i« 

tpp*  HAHE  it  (RISC_^0L7RIX) ; 
for  NAME  uro  (RZSC^OLTRZX  ->  6) ; 

SYSTEM  NAME  :  eoactaat  NAME  RISC  ULIRZX; 

SIORAtS  UNIT  :  coaatant  8; 

MEMORY  SIZE  :  coiMtant  2**31-1; 

MAX  un  :  constaat  2**31-1; 

MIN'int  :  eonjtaat  -(2**31); 

MAX~0I6ITS  ;  constant  15; 

MAX~ MANTISSA  :  constant  31; 

FINE^DEIIA  :  constant  2.0**(-31) ; 

tick”  :  constant  :■  3.906  *  10.0**(-3); 

snbtn>«  PRIORITY  is  INTEGER  rang*  0  ..  IS; 

—  Address  type 

type  ADDRESS  is  private; 

ADDRESS^ZERO  :  constant  ADDRESS; 

function  (LEFT  :  ADDRESS;  RIGHT  :  INTEGER)  return  ADDRESS; 

function  (LEFT  :  INTEGER;  RIGHT  ;  ADDRESS)  return  ADDRESS; 

function  (LEFT  :  ADDRESS;  RIGHT  :  ADDRESS)  return  INTEGER; 

function  (LEFT  :  ADDRESS;  RIGHT  :  INTEGER)  return  ADDRESS; 

—  function  (LEFT,  RIGHT  ;  ADDRESS)  return  BOOLEAN; 

—  function  (LEFT,  RIGHT  :  ADDRESS)  return  BOOLEAN; 

function  "<”  (LEFT,  RIGHT  :  ADDRESS)  return  BOOLEAN; 

function  (LEFT,  RIGHT  :  ADDRESS)  return  BOOLEAN; 

function  (LEFT,  RIGHT  :  ADDRESS)  return  BOOLEAN; 

function  (LEFT,  RIGHT  :  ADDRESS)  return  BOOLEAN; 

—  Note  that  because  ADDRESS  is  a  private  type 

—  the  functions  and  "/>”  are  already  available  and 

—  do  not  have  to  be  e:7licitly  defined 

generic 

type  TARGET  is  private; 

function  FETCH_FROM_ADDRESS  (A  :  ADDRESS)  return  TARGET; 
generic 

type  TARGET  is  private; 

procedure  ASSIGN_TO_ADDRESS  (A  :  ADDRESS;  T  :  TARGET); 

—  DEC  Ada  floating  point  type  declarations  for  the  IEEE 

—  floating  point  data  types 

type  IEEE_SINGLE_FLOAT  is  (digits  6); 
type  IEEE~DOOBLE~FLOAT  is  (digits  15); 
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tn>«  CLASS  is  (nPE  CLASS  ENUMERATION, 

ttpe“class“integer, 

TTPE~CLASS~FIXEB_POINT , 

ttpe-class'floating  point, 
ttpe~class“arrat, 
ttpe“class“record , 

TTPE~CLASS~ACCESS , 

TTPE'CLASS^TASK, 

TTPE~CLASS_ADDRESS) ; 

Non-Ads  exception 

NON  AOA_ERROR  :  exception; 

Hsxdwsre-ociented  t^^s  and  functions 

tppe  BIT  ARRAY  is  scxsy  (INTEGER  range  <>)  of  BOOLEAN; 
pragma  PACR  (BIT_ARRAr)  ; 

subtype  BIT  ARRAY  8  is  BIT  ARRAY  (0  . .  7)  ; 
subtype  BIT“arRAY~16  is  BIT^ARRAY  (0  . .  IS)  ; 
subtype  BIT~ARRAy~32  is  BIT~ARRAY  (0  . .  31) ; 
subtype  BIT2ARRAy“64  is  BIT“ARRAY  (0  . .  63) ; 

type  UNSIGNED  BYTE  is  range  0  . .  255 ; 
for  UNSIGNEU^BYTE'SIZE  use  8; 

function  "not"  (LEFT  :  ONSIGNED_BYTE)  return  UNSIGNED  BYTE; 

function  "and"  (LEFT,  RIGHT  :  UNSIGNED~BYTE)  return  DNSIGNED~BYTE; 

function  "or"  (LEFT,  RIGHT  :  UNSIGNED'bYTE)  return  UHSIGHED~BYTE; 

function  "xor"  (lEFT,  RIGHT  :  UHSIGHED~BYTE)  return  UNSIGNED~BYTE; 

function  TO  UNSIGNED  BYTE  (X  ;  BIT  ARRAY  8)  return  UNSIGNED  BYTE; 
function  TO~BIT_ARRAy_8  (X  :  ONSIGNED_BYTC)  return  BIT_ARRAY_8; 

type  UNSIGNED_BYTE_ARRAY  is  array  (INTEGER  range  <>)  of  UNSIGNED  BYTE; 

type  UNSIGNED  WORD  is  range  0  ..  65535; 
for  UNSIGNED'hord'SIZE  use  16; 

function  "not"  (LEFT  ;  ONSIGNED_WORD)  return  UNSIGNED  WORD; 

function  "and"  (LEFT,  RIGHT  ;  UNSIGNED~WORD)  return  aNSIGHED~WORD; 

function  "or"  (LEFT,  RIGHT  :  UNSIGNED'wORD)  return  UNSIGNED'wORD; 

function  "xor"  (LEFT,  RIGHT  :  OHSIGNED~WORD)  return  ONSIGNED^WORD; 

funetioc  TO  UNSIGNED  WORD  (X  :  BIT  ARRAY  16)  return  UNSIGNED  WORD; 
function  TO~BIT_ARRAY_16  (X  :  UNSIGNED_WRD)  return  BIT_ARRAY_16; 

type  UNSIGNED_WORD_ARRAY  is  array  (INTEGER  range  <>)  of  UNSIGNED  WORD; 

type  UNSIGNED  LONGWORD  is  range  MIN  INT  . .  MAX  INT; 
for  UNSIGNED~L0NGW0RD'SI2E  use  32;“ 

function  "not"  (LEFT  ;  UNSIGNED_LONGWORD)  return  UNSIGNED  LONGWORD; 

function  "and"  (LEFT,  RIGHT  :  UHSIGNED“lONGWDRD)  return  UNSIGNED'LONGWORD; 

function  "or"  (LEFT,  RIGHT  :  DNSIGNED“lONGWORD)  return  DNSIGNED“lONGWORD; 

function  "xor"  (LEFT,  RIGHT  ;  UNSIGNED  LONGWORD)  return  UNSIGNED~L0N6W0RD; 
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function  TO  UNSIGNED  LONGNORD  (X  :  BIT  ARRA7_32) 
ntuxn  UNSIGNED  L0N6N0RD; 

function  T0_BIT_AR^_32  (X  :  UNSIGNED_LONGHOBD)  ratuzn  BIT_AI«Ar_32; 

t^  UNSIGNED_LONGNORD_ABRAX  is 

sxx^  (INISGER  rang*  <>)  of  UNSIGNED_IiONGHOBD; 

t^fpo  UNSIGNED  QUADNORD  is  rocosd 
LO  :  UNSIGNED  LONGNDRD; 

LI  :  UNSIGNED~LONGRORD; 

•nd  SMOcd;  ~ 

for  UNSIGNED_QUADNORD'SIZS  uso  64; 

function  "not”  (LEFT  :  UNSIGNED  QUADHORD)  cstuxn  UNSIGNED  QUADWQRD; 

function  "and"  (LEFT,  RIGHT  :  UNSIGNED~QUAOHORD)  ntuxn  UNSIGNED~QUADNORD; 

function  "or”  (LEFT,  RIGHT  :  UNSIGNED'quadrorD)  xatucn  UNSI6NED~(3UADNORD; 

function  "xor*  (LEFT,  RIGHT  :  UNSIGNED^QUADfSORD)  ntuzn  UNSIGNED~QUADtK)RD; 

function  TO  UNSIGNED  QUADNORD  (X  ;  BIT  ARRAT  64) 
ntuxn  UNSIGNED  QUADWORD; 

function  TO_BIT_ARRAy_64  (X  ;  UHSIGNED_QDADWORD)  toturn  BIT_ARRAX_64  ; 

typo  UNSIGNED_QUADNORD_ARRAr  iS 

amy  (INTEGER  canga  <>)  of  UNSIGNED_QUADWORD; 

function  TO  ADDRESS  (X  :  INTEGER)  ntuzn  ADDRESS; 

function  TO~ADDRESS  (X  :  UNSIGNED_L0N6N0RD)  ntuzn  ADDRESS; 

function  T0~ADDR£SS  (X  :  {universal_integer})  ntuzn  ADDRESS; 

function  TO  INTEGER  (X  :  ADDRESS)  ntuzn  INTEGER; 

function  TO~UNSIGNEO_LONGNORD  (X  ;  ADDRESS)  ntuzn  UNSIGNED_LONGHORD; 

—  Conventional  names  for  static  subtypes  of  type  UNSIGNED_LONGNORD 

subtype  UNSIGNED  1  is  UNSIGNED  LONGHORD  range  0  ..  2**  1-1; 

subtype  UNSIGNED"!  is  UNSIGNED^LONGWORD  range  0  ..  2**  2-1; 

subtype  UNSIGNED"!  is  UNSIGNED  LONGNORD  range  0  ..  2**  3-1; 

subtype  UNSIGNED"4  is  UNSIGNED"longHORD  range  0  ..  2**  4-1; 

subtype  UNSIGNED"!  is  UNSIGNED"l0NGH0RD  range  0  ..  2**  5-1; 

subtype  UNSIGNED"!  is  UNSIGNED"lONGHORC  range  0  ..  2**  6-1; 

subtype  UNSIGNED"7  is  UNSIGNED_LONGWDRD  range  0  ..  2**  7-1; 

subtype  UNSIGNED"8  is  UNSIGNED  LONGNORD  range  0  ..  2**  8-1; 

subtype  UNSIGNED"!  is  UNSIGNED"lONGNORD  range  0  ..  2**  9-1; 

subtype  UNSIGNED"10  is  UNSIGNED~LONGWORD  zange  0  ..  2**10-1; 

subtype  UNSIGNED"11  is  UNSIGNED  LONGRORD  range  0  ..  2**11-1; 

subtype  UNSIGNED"12  is  UNSIGNED"LONGRORD  range  0  ..  2**12-1; 

subtype  UNSIGNEd"13  is  UNSIGNED"lON6RORD  range  0  ..  2**13-1; 

subtype  UNSIGNED"14  is  UNSIGNED^LONGRORD  range  0  ..  2**14-1; 

subtype  UNSIGNED"15  is  UNSIGNED  LONGRORD  range  0  ..  2**15-1; 

subtype  UNSIGNED"16  is  UNSIGNED"L0NGR0RD  range  0  ..  2**16-1; 

subtype  UNSIGNE0"l7  is  UNSIGNED"lON6RORD  range  0  ..  2**17-1; 

subtype  UNSIGNED"18  is  UNSIGNED"lONGRORD  range  0  . .  2**18-1; 

subtype  UNSIGNED"19  is  UNSIGNED"lONGRORD  range  0  ..  2**19-1; 

subtype  UNSIGNED~20  is  UNSIGNED"L0NGR0RD  range  0  ..  2**20-I; 
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snbtj^  nNSIGIIED_21  is  0NSIGIlEO_LON6f9ORO  ssnga  0 
subtyps  UNSIG1IED~22  is  tniSIGNED~LOI)GWORO  rang*  0 
svbtyp*  aNSIGNEO~23  is  nNSIGNEO~LONGIiORO  range  0 
subtype  UNSIGI1ED~24  is  UNS1G11ED~L0N6R0R0  range  0 
subtype  UNSI611ED~25  is  UNSIGNED'loNSHORD  range  0 
snbtype  UNSIGIIEO~26  is  ONSIGMEO^liOIIGNORD  range  0 
snbtype  nNSIGIIEO_27  is  tJNSZ6NE0~L0N6R0R0  range  0 
subtype  ONSIGI]EO~28  is  nNSIGNED~L0N6{i0R0  range  0 
snbty^  0I1SZ611E0~29  is  aMSZGNED~I,OMGRORO  range  0 
snbtype  UNSZG11ED~30  is  ONSZGNEO'loNGHORO  range  0 
snbtype  aNSZGHE0~31  is  UNSZGNEO'loNGROIU)  range  0 

—  Function  for  obtaining  global  symbol  values 


2**21-1; 

2»*22-l; 

2**23-l; 

2**24-l; 

2**25-l; 

2**26-l; 

2**27-l; 

2**28-l; 

2**29-l; 

2**30-l; 

2**31-1; 


function  ZMPORT_VALOE  (SZMBOL  :  SIRZMG)  return  aNSZGlIED_LONGWOIU); 
private 


—  Not  showi 


end  SZSTEM; 


F.4  Restrictions  on  Representation  Clauses 

The  representation  clauses  allowed  in  DEC  Ada  are  length,  enumeration, 
record  representation,  and  address  clauses. 

In  DEC  Ada,  a  representation  clause  for  a  generic  formal  type  or  a  type  that 
depends  on  a  generic  formal  type  is  not  allowed.  In  addition,  a  representation 
clause  for  a  composite  type  that  has  a  component  or  subcomponent  of  a  generic 
formal  type  or  a  type  derived  from  a  generic  formal  type  is  not  allowed. 

F.5  Restrictions  on  Unchecked  Type  Conversions 

DEC  Ada  supports  the  generic  function  UNCHECKED_CONVEESION  with 
the  following  restrictions  on  the  class  of  types  involved: 

*  The  actual  subtype  corresponding  to  the  formal  type  TARGET  must  not  be 
an  unconstrained  array  type. 

*  The  actual  subtype  corresponding  to  the  formal  type  TARGET  must  not  be 
an  unconstrained  type  wi(^  discriminants. 

Further,  when  the  target  type  is  a  type  with  discriminants,  the  value  resulting 
from  a  call  of  the  conversion  function  resiilting  from  an  instantiation  of 
UNCHECKED.CONVERSION  is  checked  to  ensure  that  the  discriminants 
satisfy  the  constraints  of  the  actual  subtype. 


2-11 


Restrictions  on  Unchecked  Type  Conversions  F.5 


Impiamentation-Oependent  Characteristics 


If  the  size  of  the  source  value  is  greater  than  the  size  of  the  target  subtype, 
then  the  high  order  bits  of  the  value  are  ignored  (truncated);  if  the  size  of 
the  source  value  is  less  than  the  size  of  the  target  subtype,  then  the  value  is 
extended  with  zero  bits  to  form  the  result  value. 

F.6  Conventions  for  Implementation-Generated  Names 
Denoting  Implementation-Dependent  Components  in 
Record  Representation  Clauses 

DEC  Ada  does  not  allocate  implementation-dependent  components  in  records. 

F.7  Interpretation  of  Expressions  Appearing  in  Address 
Clauses 

Expressions  appearing  in  address  clauses  must  be  of  the  type  ADDRESS 
de^ed  in  the  package  SYSTEM  (see  13.7a.l  and  F.3).  In  DEC  Ada,  values  of 
type  SYSTEM.ADDRESS  are  interpreted  as  virtual  addresses  in  the  machine’s 
address  space. 

DEC  Ada  allows  address  clauses  for  objects  (see  13.5). 

DEC  Ada  does  not  support  interrupts  as  defined  in  section  13.5.1. 

(Dn  VMS  systems,  DEC  Ada  provides  the  pragma  AST_ENniY  and  the 
AST.ENTRY  attribute  as  alternative  mechanisms  for  handling  asynchronous 
interrupts  fium  the  VMS  operating  system  (see  9.12a). 

F.8  Implementation-Dependent  Characteristics  of 
Input-Output  Packages 

In  addition  to  the  standard  predefined  input-output  packages 
(SEQUENTIAL.IO,  DIRECTJO,  TEXTJO,  and  lO.EXCEPTIONS),  DEC  Ada 
provides  packages  for  handling  sequential  and  direct  files  with  mixed-type 
elements: 

•  SEQUENTIALJMIXEDJO  (see  14.2b.4). 

•  DIRECT_MIXEDJO  (see  14.2b.6). 

DEC  Ada  does  not  provide  the  package  LOW_LEVEL_IO  (except  as  part  of 
the  implementation  of  the  other  input-output  packages,  and  in  a  nonstandard 
form). 
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As  specified  in  section  14.4,  DEC  Ada  raises  the  following'  language^efined 
exceptions  for  error  conditions  that  occur  during  input-output  operations: 
STATUS_ERROR,  MODE_ERROR,  NAME.ERROR,  USE.ERROR,  END. 
ERROR,  DATA_ERROR,  and  LAY OUT.ERROR.  DEC  Ada  does  not  raise  the 
language-defined  exception  DEVICE.ERROR;  device-related  errors  cause  the 
exception  USE_ERROR  to  be  raised. 

The  exception  USE.ERROR  is  raised  under  the  following  conditions: 

•  If  the  capacity  of  the  external  file  has  been  exceeded. 

•  In  all  CREATE  operations  if  the  mode  specified  is  IN.FILE. 

•  In  all  CREATE  operations  if  the  file  attributes  specified  by  the  FORM 
parameter  are  not  supported  by  the  package. 

•  In  all  CREATE,  OPEN,  DELETE,  and  RESET  operations  if,  for  the 
specified  mode,  the  environment  does  not  support  the  operation  for  an 
external  file. 

•  In  all  NAME  operations  if  the  file  has  no  name. 

•  In  the  SET.UNE.LENGTH  and  SET.EAGE.LENGTH  operations  on  text 
files  if  the  lengths  specified  are  inappropriate  for  the  external  file. 

•  In  text  files  if  an  operation  is  attempted  that  is  not  possible  for  reasons 
that  depend  on  characteristics  of  the  external  file. 

DEC  Ada  provides  other  input-output  packages  that  are  available  on  specific 
systems.  The  following  sections  outline  those  packages.  The  following  sections 
also  give  system-specific  information  about  the  overall  set  of  DEC  Ada 
input-output  packages  and  input-output  exceptions. 

F.8.1  DEC  Ada  input>Output  Packages  on  VMS  Systems 

On  VMS  systems,  the  DEC  Ada  predefined  packages  and  their  operations  are 
implemented  using  VMS  Record  Management  Services  (RMS)  file  organizations 
and  facilities.  To  give  users  the  maximum  benefit  of  the  imdeiiying  VMS  RMS 
input-output  facilities,  DEC  Ada  provides  the  following  VMS-specific  packages: 

•  REIATIVE.IO  (see  14.2a.3). 

•  INDEXED.IO  (see  14.2a.5). 

•  RELATIVE_MIXEDJO  (see  14.2b.8). 

•  INDEXED_MIXED_IO  (see  14.2b.  10). 

•  AUXJO.EXCEPTIONS  (see  14.5a). 
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’Die  following  sections  summarize  the  implementation*dependent  characteris¬ 
tics  of  the  DEC  Ada  input-output  packages.  The  VAX  Ada  Run-Ume  Reference 
Manual  discusses  these  characteristics  in  more  detail. 

F.8.1.1  Interpretation  of  the  FORM  Parameter  on  VMS  Systems 

On  VMS  s3rstems,  the  value  of  the  FORM  parameter  may  be  a  string  of 
statements  of  the  VMS  Record  Management  Services  (Rh^)  File  Definition 
Language  (FDD,  or  it  may  be  a  string  referring  to  a  text  file  of  FDL  statements 
(called  an  FDL  ^e). 

FDL  is  a  special-purpose  VMS  language  for  writing  file  specifications.  These 
specifications  are  then  \ised  by  DEC  Ada  run-time  routines  to  create  or  open 
files.  See  the  VAX  Ada  Run-Time  Reference  Manual  for  the  rules  governing  the 
FORM  parameter  and  for  a  general  description  of  FDL.  See  the  Guide  to  VMS 
File  Applications  and  the  VMS  File  Definition  Language  Facility  Manual  for 
complete  information  on  FDD 

On  VMS  systems,  each  input-output  package  has  a  default  string  of  FDL 
statements  that  is  used  to  open  or  create  a  file.  Thus,  in  general,  specification 
of  a  FORM  parameter  is  not  necessary:  it  is  never  necessary  in  an  OPEN 
procedure;  it  may  be  necessary  in  a  (CREATE  procedure.  The  packages  for 
which  a  value  for  the  FORM  parameter  must  be  specified  in  a  d^REATE 
procedure  are  as  follows: 

•  The  packages  DIRECT_IO  and  RELAUVE.IO  require  that  a  maximum 
element  (record)  size  be  specified  in  the  FORM  parameter  if  the  item  with 
which  the  package  is  instantiated  is  unconstrained. 

•  The  packages  DIRECT_MECED_IO  and  RELATTVE_MECED_IO  require 
that  a  maximum  element  (record)  size  be  specified  in  the  FORM  parameter. 

•  The  packages  INDEXEDJO  and  INDEXED_MDCED_IO  require  that 
information  about  keys  be  specified  in  the  FORM  parameter. 

Any  explicit  FORM  specification  supersedes  the  default  attributes  of  the 
governing  input-output  package.  The  VAX  Ada  Run-Time  Reference  Manual 
describes  the  default  external  file  attributes  of  each  input-output  package. 

The  use  of  the  FORM  parameter  is  described  for  each  input-output  package  in 
chapter  14.  For  information  on  the  default  FORM  parameters  for  each  DEC 
Ada  input-output  package  and  for  information  on  using  the  FORM  paraTn<»ti»r 
to  specify  external  file  attributes,  see  the  VAX  Ada  Run-Time  Reference 
Manual.  For  information  on  FDL,  see  the  Guide  to  VMS  File  Applications 
and  the  VMS  File  Definition  Language  Facility  Mamutl. 
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F.8.1^  Input-Output  Exceptions  on  VMS  Systems 

In  addition  to  the  OEC  Ada  exceptions  that  apply  on  all  systems,  the  following 
also  apply  on  VMS  systems: 

•  The  DEC  Ada  exceptions  LOCK_ERROR,  EDQSTENCE.ERROR,  and  KEIY_ 
ERROR  are  raised  for  relative  and  indexed  input-output  operations. 

•  The  exception  USE_ERROR  is  raised  as  follows  in  relative  and  indexed 
files: 

—  In  the  WRITE  operations  on  relative  or  indexed  files  if  the  element  in 
the  position  indicated  has  already  been  written. 

—  In  the  DELETE.ELEMENT  operations  on  relative  and  indexed  files  if 
the  current  element  is  undefined  at  the  start  of  the  operation. 

-  In  the  UPDATE  operations  on  indexed  files  if  the  current  element  is 
undefined  or  if  the  specified  key  violates  the  external  file  attributes. 

*  The  exception  NAME_ERROR  is  raised  as  specified  in  section  14.4:  by  a 
call  of  a  CREATE  or  OPEN  procedure  if  the  string  given  for  the  NAME 
parameter  does  not  allow  the  identification  of  an  external  file.  On  VMS 
systems,  the  value  of  a  NAME  parameter  can  be  a  string  that  denotes  a 
VMS  file  specification  or  a  VMS  logical  name  (in  either  case,  the  string 
names  an  external  file).  For  a  CREIATE  procedure,  the  value  of  a  NAME 
parameter  can  also  be  a  null  string,  in  which  case  it  names  a  temporary 
external  file  that  is  deleted  when  the  main  program  exits.  The  VAX  Ada 
Run-Time  Refd-ence  Manual  explains  the  naming  of  external  files  in  more 
detail. 

*  The  exception  LAYOUT.ERROR  is  raised  as  specified  in  section  14.4:  in 
text  input-output  by  COL,  LINE,  or  PAGE  if  the  value  returned  exceeds 
COUNT'  LAST.  The  exception  LA5rOUT_ERROR  is  also  raised  on  output  by 
an  attempt  to  set  column  or  line  numbers  in  excess  of  specified  maximum 
line  or  page  lengths,  and  by  attempts  to  PUT  too  many  characters  to 

a  string.  In  the  DEC  Ada  mixed  input-output  packages,  the  exception 
LAYOUT_ERROR  is  raised  by  GET_ITEM  if  no  more  items  can  be  read 
from  the  file  buffer;  it  is  raised  by  PUT.ITEM  if  the  current  position 
exceeds  the  file  buffer  size. 
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F.8.2  Input-Output  Packages  on  ULTRIX  Systems 

On  ULTRIX  sjrstems,  the  DEC  Ada  predefined  packages  and  their  operations 
are  implemented  using  ULTIUX  file  facilities.  DEC  Ada  provides  no  additional 
input-output  packages  specifically  related  to  ULTRIX  systems. 

The  following  sections  summarize  the  ULTRIX-spedfic  characteristics  of  the 
DEC  Ada  input-output  packages.  The  DEC  Ada  Run-Time  Reference  Manual 
for  ULTRIX  Systems  discusses  these  charactmistics  in  more  detail. 

F.8^1  Interpretation  of  the  FORM  Parameter  on  ULTRIX  Systems 

On  ULTRIX  systems,  the  value  of  the  FORM  parameter  must  be  a  character 
string,  defined  as  follows: 

string  :  s—  "[field  (,  field)]" 

field  :  :•*«  field_id  ■>  field_y«lue 

field_id  :  BOITER_SI2E  I  EI,EMENT_SI2E  I  FllE^DESCRIPTOR 

field^velue  : digit  . (digit) 

Depending  on  the  fields  specified,  the  value  of  the  FORM  parameter  may 
represent  one  or  more  of  the  following: 

•  The  size  of  the  buffer  used  during  file  operations.  The  field  value  specifies 
the  number  of  bytes  in  the  buffer. 

•  The  TnaTimiiTn  element  size  for  a  direct  file.  The  field  value  specifies  the 
TnaxiTniiTn  number  of  bytes  in  the  element. 

•  An  ULTRIX  file  descriptor  for  the  Ada  file  being  opened.  The  ULTRIX  file 
descriptor  mxist  be  open. 

If  the  file  descriptor  is  not  open,  or  if  it  refers  to  an  Ada  file  that  is 
already  open,  then  the  exception  USE_ERROR  is  raised.  Note  that  the 
file  descriptor  option  can  be  used  only  in  the  FORM  parameter  of  an  OPEN 
procedure. 

Each  input-output  package  has  an  implementation-defined  value  form  string 
that  is  used  to  open  or  create  a  file.  Thus,  in  goieral,  specification  of  a  FORM 
parameter  is  not  necessary.  The  packages  for  which  a  value  for  the  FORM 
parameter  must  be  specified  in  a  CREATE  procedure  are  as  follows: 

•  The  package  DIRECT_IO  requires  that  a  maximum  element  size  be 
specified  in  the  FORM  parameter  if  the  item  with  which  the  package  is 
instantiated  is  unconstrained. 

•  The  package  DIRECT_MIXED.IO  requires  that  a  maximum  element  size 
be  specified  in  the  FORM  parameter. 


Interpretation  o1  the  FORM  Parameter  on  ULTRIX  Systems  F.8.2.t 
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The  use  of  the  FORM  parameter  is  described  for  each  input-output  package  in 
chapter  14.  For  information  on  using  the  FORM  parameter  to  specify  external 
file  attributes,  see  the  DEC  Ada  Run-Time  Reference  Manual  for  ULTRIK 
Systems. 

F.8JL2  Input-Output  Exceptions  on  ULTRIX  Systems 

In  addition  to  the  DEC  Ada  exceptions  that  apply  on  all  systems,  the  following 
also  apply  on  ULTRIX  systems: 

*  The  exception  NAME.ERROR  is  raised  as  specified  in  section  14.4:  by  a 
call  of  a  CREIATE  or  OPEN  procedure  if  the  string  given  for  the  NAME 
parameter  does  not  allow  the  identification  of  an  external  file.  On  ULTRIX 
systems,  the  value  of  a  NAME  parameter  can  be  a  string  that  denotes  an 
ULTRIX  file  specification.  For  a  CREATE  procedure,  the  value  of  a  NAME 
parameter  can  also  be  a  nuU  string,  in  which  case  it  names  a  temporary 
external  file  that  is  deleted  when  the  main  program  exits.  The  DEC  Ada 
Run-Time  Ref&ence  Manual  for  ULTRIX  Systems  explains  the  naming  of 
external  files  in  more  detail. 

*  The  exception  LAYOUT.ERROR  is  raised  as  specified  in  section  14.4:  in 
text  input-output  by  COL,  LINE,  or  PAGE  if  the  value  returned  exceeds 
COUNT'  LAST.  The  exception  LAYOUT.ERROR  is  also  raised  on  output  by 
an  attempt  to  set  column  or  line  numbers  in  excess  of  specified  TnaTimiiTo 
line  or  page  lengths,  and  by  attempts  to  PUT  too  many  characters  to 

a  string.  In  the  DEC  Ada  mixed  input-output  packages,  the  exception 
LA5rOUT_FRTlOR  is  raised  by  GET_rTEM  if  no  more  items  be  read 
from  the  file  buffer;  it  is  raised  by  PUT.ITEM  if  the  current  position 
exceeds  the  file  buffer  size. 

F.9  Other  Implementation  Characteristics 

Implementation  characteristics  relating  to  the  definition  of  a  main  program, 
various  numeric  ranges,  and  implementation  limits  are  summarized  in  the 
following  sections. 

F.9.1  Definition  of  a  Main  Program 

DEC  Ada  permits  a  library  unit  to  be  used  as  a  main  program  under  the 
following  conditions: 

*  If  it  is  a  procedure  with  no  formal  parameters. 

On  VMS  systems,  the  status  returned  to  the  VMS  environment  upon 
normal  completion  of  the  procedure  is  the  value  1. 

On  ULTRIX  systems,  the  status  returned  to  the  ULTRIX  environment 
upon  normal  completion  of  the  procedure  is  the  value  0. 
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*  If  it  is  a  fonction  with  no  fonnal  parameters  whose  returned  value  is  of 
a  discrete  type.  In  this  case,  the  status  returned  to  the  operating-system 
environment  upon  normal  completion  of  the  function  is  the  function  value. 

*  If  it  is  a  procedure  declared  with  the  pragma  £IXPORT_VALUED_ 
PROCEDURE,  and  it  has  one  formal  oat  parameter  that  is  of  a  discrete 
type.  In  this  case,  the  status  returned  to  the  operating-system  environment 
upon  normal  completion  of  the  procedure  is  the  value  of  the  first  (and  only) 
parameter. 

Note  that  when  a  main  function  or  a  main  procedure  declared  with  the  pragma 
EXPORT_VALUED_PROCEDURE  retiims  a  discrete  value  whose  aiga  is  less 
than  32  bits,  the  value  is  zero-  or  sign-extended  as  appropriate. 

F.9.2  Values  of  Integer  Attributes 

The  ranges  of  values  for  integer  types  declared  in  the  package  STANDARD  are 
as  follows; 


Integer  type 

Range 

Systems  on  which  it 
appiies 

SHORT.SHORTJNTEGER 

-128  ..  127 

AU 

SHORT_INTEGER 

-32768  ..  32767 

AU 

INTEGER 

-2U7483648  ..  2147483647 

AU 

F.g.2  Values  of  Integer  Attributes 
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For  the  applicable  input-output  packages,  the  ranges  of  values  for  the  types 
COUNT  and  POSITIVE.COUNT  are  as  follows: 

COUNT  0  ..  INTEGER'  LAST 

POSmVE_COUNT  1 ..  INTEGER'  LAST 

For  the  package  TEXTJLO,  the  range  of  values  for  the  type  FIELD  is  as  follows: 
FIELD  0  ..  INTEGER'  LAST 

F.9.3  Values  of  Floating  Point  Attributes 

DEC  Ada  provides  a  number  of  predefined  floating  point  types,  as  shown  in  the 
following  table: 


Type 

Representation 

Systems 
on  which  It 
applies 

Section 

FLOAT 

F.fioating 

IEEE  single  float 

VMS 

ULTRK 

3.5.7 

LONG_FLOAT 

D_floating  or  G.floating 
IEEE  do^le  float 

VMS 

ULTRK 

3.5.7 

LONG_LONG_FLOAT 

H_floating 

VMS 

3.5.7 

F.FLOAT 

F_floating 

VMS 

3.5.7 

D_FLOAT 

D_floating 

VMS 

3.5.7 

G.FLOAT 

G_floatmg 

VMS 

3.5.7 

H.FLOAT 

K_floating 

VMS 

3.5.7 

IEEE_SINGLE_FLOAT 

IEEE  single  float 

ULTRIX 

3.5.7 

IEEE_DOUBLE_FLOAT 

TEEE  double  float 

xn^TRix 

3.5.7 

The  values  of  the  floating  point  attributes  for  the  different  floating  point 
representations  appear  in  the  following  tables. 


F.9.3.1  FJIoating  Characteristics 


F_floatlng  value  and  approximate  decimal  equivalent 
Attribute  (v^ere  applicable) 

DIGITS  6 

MANTISSA  21 
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Attribute 

F.fioating  value  and  approximate  decimal  equivalent 
(where  applieabie) 

EMAX 

84 

EPSILON 

16«0.1000_000#e-4 

approziinately 

9.53674EM)7 

SMALL 

16«0.8000.000#e-21 

apprroziinataly 

2.58494E-26 

LABGE 

16#0.PFPF_P80#e+21 

approzixnately 

L93428E+25 

SAFE.EMAX 

127 

SAFE.SMALL 

16#0.1000_000#e-31 

approximately 

2.93874E-39 

SAFE.LABGE 

16#0.7PFF_FC0#e+32 

approximately 

1.70141E+38 

HRST 

-16#0.7FFF_FF8#e+32 

approximately 

-1.70U1E+38 

LAST 

16#0.7FFF_FF8#e+32 

approximately 

L70141E+38 

MACHINE.RADIX 

2 

MACHINE_MANnSSA 

24 

MACHINE_EMAX 

127 

MACHINE_EMIN 

-127 

MACHINE.ROUNDS 

TVue 

MACHINE_OVERFLOWS 

True 

F.9.3.2  OJIoating  Characteristics 


Attribute 

□.floating  value  and  approximate  dedmsi  equivalent 
(\^ere  applicable) 

DIGITS 

9 

MANTISSA 

31 

EMAX 

124 

EPSILON 

16#0.4000_0000  0000_000#e-7 

approximately 

9.3132257461548E-10 

□.floating  Charactaristics  F.9.3.2 
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Attribute 

D_floating  value  and  approzimate  decimal  equivalent 
(t^are  applicable) 

SMALL 

approxiinately 

16*0.8000  0000  0000  000*e-31 

2.3509887016446E-38 

LARGE 

approziinately 

16#0.FFFP  FFFE  0000  000#e+31 

2.12676479226S5E+37 

SAFE.EMAX 

127 

SAFE.SMALL 

approamately 

16*0.1000  0000  0000  000*e-31 

2.9387358770557E-39 

SAFE.LARGE 

approzimately 

16*0.7FFP_FFFP_0000_000*e+32 

1.70U118338124E-f38 

FIRST 

approzimately 

-16*0.7FFF_FFFP_PFFF  FF8*e+32 
-L7014118346047E+38 

LAST 

approzimately 

16*0.7FFF_FFFF_FFFF_FF8#e+32 

L7014118346047E+38 

MACHINE.RADIX 

2 

MACHINE.MANnSSA 

56 

MACHINE.EMAX 

127 

MACHINE.EMIN 

-127 

MACHINE.ROUNDS 

IVue 

MACHINE_OVERFLOWS 

TVue 

F.9.3.3  QJIoatIng  Characteristics 


Attribute 

G_floating  value  and  approzimate  decimal  equivalent 
(where  applicable) 

DIGITS 

15 

MANTISSA 

51 

EMAX 

204 

EPSILON 

approzimately 

16*0.4000  0000.0000  00*e-12 

8.881784197001E-16 

SMALL 

approzimately 

16*0.8000  0000  0000  00*e-51 

1.944692274332E-62 

LARGE 

approzimately 

16*0.FFFP  FFFF  FFFF  E0*e4-51 

2.571100870814E+61 
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Attribute 

G_fioating  value  and  approximate  decimal  equivalent 
(whara  applieabla) 

SAFE_EMAX 

1023 

SAFE.SMALL 

approximately 

16«0.1000  0000  0000.00#e-255 

S.562684646268E-309 

SAFE_LARGE 

approximately 

16#0.7FFF  FFFF_FFFF_P0#e+256 

8.988465674312E+307 

FIRST 

approximately 

-16#0.7FPF_FFFF_FFPP_FC#e+256 

-8.988465674312E+307 

LAST 

approximately 

16#0.7FFF  FFFF_FFFF_FC#e+256 

8.98846S674312E+307 

MACHINE.RADIX 

2 

MACHINE.MANTISSA 

53 

MACHINE.EMAX 

1023 

MACHINE.EMIN 

-1023 

MACHINE.ROUNDS 

IVue 

MACHINE.OVERFLOWS 

True 

F.9.3.4  HJIoatIng  Characteristics 

Attributa 

H_floating  value  and  approximate  decimal  aquivalant 
(where  applicable) 

DIGITS 

33 

MANTISSA 

111 

EMAX 

444 

EPSILON 

approximately 

16#0.4000_0000  OOOO.OOOO.OOOO  0000  0000  0#e-27 
7.70371977754894341222391177033971&-34 

SMALL 

approximately 

16#0.8000_0000_0000_0000_0000  0000  0000  0#e-lll 
1.1006568214837918210934318020936^134 

LARGE 

approximately 

16#0.FFFF_FFrFJTFF_FFFP  FFFF  FFFF  FFFE  0#e+lll 
4.5427420268475430659332737993000E^133 

SAFE.EMAX 

16383 

SAFE.SMALL 

approximately 

16#0.1000_0000  OOOO.OOOO.OOOO  0000  0000  0#e^095 
8.4052578577802337656566945433044E-4933 

HJIoating  Characteristics  F.9.3.4 
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Attribute 

H_floating  value  and  approximate  dedmai  equivalent 
(where  applicable) 

SAFE_LARGE 

approziinately 

16#0.7PFP_FFFF  FFFF  FFFP_PFFF  FPFF  FFFF_0#e+4096 
5.9486574767861S88254287966331400E^931 

FIRST 

approziinacely 

-16#0.7FFF  FFFF  FFFF  FFFF  FFFF  FFFF  FFFF_C#e+4096 
-S.94866747678615i3825428796^1406E+493l 

LAST 

approximately 

16#0.7FFF _FFFF  FFFF  FFFF.FFFF  FFFF  FFFF_C#e+4096 
5.94866747678615882542879€6331400E4493~1 

MACHINE.RADIX 

2 

MACHINE.MANTISSA 

113 

MACHINE_EMAX 

16383 

MACHINE.EMrN 

-16383 

MACHINE.ROUNDS 

Tme 

MACHINE.OVERFLOWS 

True 

F.9.3.5  IEEE  Single  Float  Characteristics 

Attribute 

IEEE  single  float  value  and  approximate  decimal  equivalent 
(where  applicable) 

DIGITS 

6 

MANTISSA 

21 

EMAX 

84 

EPSILON 

16#0.1000_000#e-4 

approximately 

9.53674E-07 

SMALL 

16#0.8000_000#e-21 

approximately 

2^849E)-26 

LARGE 

16#0.FFFF_F80#E+2 1 

approximately 

1.93428E-»-25 

SAFE.EMAX 

125 

SAFE.SMALL 

approximately 

1.17549E-38 

SAFE.LARGE 

approximately 

4.25353E-K37 

FIRST 

approximately 

-3.40282E-i^8 
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Attribute 

IEEE  single  float  value  and  approximate  decimal  equivalent 
(where  applicable) 

LAST 

approziznately 

3.40282E+38 

MACmNE.RADK 

2 

MACHINE.MANTISSA 

24 

MACHINE.EMAX 

128 

MACHINE_EMIN 

-125 

MACHINE.ROUNDS 

TViie 

MACHINE.OVERFLOWS 

True 

F.9.3.6  IEEE  Double  Roat  Characteristics 


Attribute 

IEEE  double  float  value  and  approximate  decimal  equivalent 
(where  applicable) 

DIGITS 

15 

MANTISSA 

51 

EMAX 

204 

EPSILON 

approximately 

8.8817841970012E-16 

SMALL 

approximately 

1.9446922743316E-62 

LARGE 

approximately 

2.5711008708144E+61 

SAFE.EMAX 

1021 

SAFE.SMALL 

approximately 

2.22507385850720E-308 

SAFE.LARGE 

approximately 

2.2471164185779E+307 

FIRST 

approximately 

-1.7976931348623E>308 

LAST 

approximately 

1.7976931348623E-»^08 

MACmNE.RADK 

2 

MACHINE_MANTISSA 

53 

IEEE  Double  Roat  Characteristics  F.9.3.6 
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Attribute 

IEEE  double  float  value  and  approximate  decimal  equivalent 
(where  applicable) 

MACHINE.EMAX 

1024 

MACHINE_EMIN 

-1021 

MACHINE_ROUNDS 

True 

MACHINE.OVERFLOWS 

IVtte 

F.9.4  Attributes  of  Type  DURATION 

The  values  of  the  significant  attributes  of  the  type  DURATION  are  as  follows: 


DURATION'  DELTA 
DURATION'  SMALL 
DURATION' FIRST 
DURATION' LAST 
DURATION' LARGE 


0.0001 

2-u 

-131072.0000 

131071.9999 

131071.9999 


F.9.5  Implementation  Limits 


Limit 

DEC 
systems 
on  which  It 
applies 

Value 

Maximum  number  of  formal  parameters  in  a 
subprogram  or  entry  declaration  that  are  of  an 
unconstrained  record  type 

All 

32 

Maximum  identifier  length  (number  of  characters) 

All 

255 

Maximum  number  of  characters  in  a  source  line 

All 

255 

Maximum  number  of  discriminants  for  a  record  type 

All 

245 

Maximum  number  of  formal  parameters  in  an  entry  or 
subprogram  declaration 

All 

246 

Maximum  number  of  dimensions  in  an  array  tjrpe 

All 

255 

Maximum  number  of  library  units  and  subunits  in  a 
compilation  closure* 

All 

4095 

’’nia  compilatiini  dosnra  of  a  givan  unit  ia  tho  total  aat  of  unit#  tht  tha  givan  unit  dapanda  on, 
diractly  and  indiractly. 
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Limit 

DEC 
systams 
on  which  It 
appliM 

Value 

MaxitmiTn  number  of  library  units  and  subunits  in  an 
execution  closure^ 

All 

16383 

Maximum  ntunber  of  otqecta  declared  with  the  pragma 
COMMON.OBJECT  or  PSECT.OBJECT 

AU 

32757 

Maximum  number  of  enumeration  literals  in  an 
enumeration  type  defixiition 

AU 

65535 

Maximum  number  of  lines  in  a  source  file 

An 

65534 

Maximum  number  of  bits  in  any  object 

AU  . 

2**-l 

Maximum  size  of  the  static  portion  of  a  stack  fiame 

AU 

2**  -  12 

^The  exeeatiaa  closure  of  a  giTan  unit  is  tbs  oompilatioB  dosure  plus  all  assnoatsd  ascondary  uaits 
library  bodiss  and  cobniutsi. 

F.9.5  Implementation  Limits 
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